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. 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
