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 >
