Hi,

2013/2/6 Gary Gregory <garydgreg...@gmail.com>

> IMO, any [commons] component can update it's Java requirement as it sees
> fit. I would rather see /one/ [math] component instead of two.
>
> My advise would be to (1) plan for a version 3.2 that is based Java 6 or 7
> and release 3.1.x versions for bug fixes only.
>

can we do this in a minor release?


>
> Alternatively, you could (1) plan for a version 4.0 that is based Java 6 or
> 7 and release 3.x versions for bug fixes AND back-port of 4.0 features,
> where 3.x does NOT change Java versions.


> Gary
>
>
> On Tue, Feb 5, 2013 at 9:08 AM, Gilles <gil...@harfang.homelinux.org>
> wrote:
>
> > Hi.
> >
> > In the thread about "static import", Stephen noted that decisions on a
> > component's evolution are dependent on whether the future of the Java
> > language is taken into account, or not.
> > A question on the same theme also arose after the presentation of Commons
> > Math in FOSDEM 2013.
> >
> > If we assume that efficiency is among the important qualities for Commons
> > Math, the future is to allow usage of the tools provided by the standard
> > Java library in order to ease the development of multi-threaded
> algorithms.
> >
> > Maintaining Java 1.5 source compatibility for the reason that we may need
> > to support legacy applications will turn out to be self-defeating:
> > 1. New users will not consider Commons Math's features that are notably
> >    apt to parallel processing.
> > 2. Current users might at some point simply switch to another library if
> >    it proves more efficient (because it actually uses multi-threading).
> > 3. New Java developers will be turned away because they will want to use
> >    the more convenient features of the language in order to provide
> >    potential contributions.
> >
> > If maintaining 1.5 source compatibility is kept as a requirement, the
> > consequence is that Commons Math will _become_ a legacy library.
> > In that perspective, implementing/improving algorithms for which a
> > parallel version is known to be more efficient is plainly a waste of
> > development and maintenance time.
> >
> > In order to mitigate the risks (both of upgrading and of not upgrading
> > the source compatibility requirement), I would propose to create a new
> > project (say, "Commons Math MT") where we could implement new features[1]
> > without being encumbered with the 1.5 requirement.[2]
> > The "Commons Math MT" would depend on "Commons Math" where we would
> > continue developing single-thread (and thread-safe) "tasks", i.e.
> > independent units of processing that could be used in algorithms
> > located in "Commons Math MT".
> >
> > In summary:
> > - Commons Math (as usual):
> >   * single-thread (sequential) algorithms,
> >   * (pure) Java 5,
> >   * no dependencies.
> > - Commons Math MT:
> >   * multi-thread (parallel) algorithms,
> >   * Java 7 and beyond,
> >   * JNI allowed,
> >   * dependencies allowed (jCuda).
> >
> > What do you think?
> >
> >
> > Best regards,
> > Gilles
> >
> > [1] Also, we would gradually move there the algorithms that would
> obviously
> >     benefit from a multi-thread implementation (e.g Fourier transform,
> >     genetic algorithms, etc.)
> > [2] This project would also be a place where people could experiment with
> >     "jCuda" (http://www.jcuda.org).
> >
> >
> > ------------------------------**------------------------------**---------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<
> dev-unsubscr...@commons.apache.org>
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>

Reply via email to