On 1/15/15 2:24 PM, Thomas Neidhart wrote: > On 01/08/2015 12:34 PM, Gilles wrote: >> Hi. >> >> Raising this issue once again. >> Are we going to upgrade the requirement for the next major release? >> > [ ] Java 5 > [x] Java 6 > [x] Java 7 > [ ] Java 8 > [ ] Java 9 > > A while ago I thought that it would be cool to switch to Java 7/8 for > some of the nice new features (mainly fork/join, lambda expressions and > diamond operator, the rest is more or less unimportant for math imho). > > But after some thoughts I think they are not really needed for the > following reasons: > > * the main focus of math is on developing high-quality, well tested and > documented algorithms, the existing language features are more than > enough for this
+1 > > * coming up with multi-threaded algorithms might be appealing but it is > also hard work and I wonder if it really makes sense in the times of > projects like mahout / hadoop / ... which aim for even better scalability +1 My HO is we should focus on getting the best single-threaded implementations we can and, where possible, setting things up to be executed in parallel by other engines. Spawning and managing threads internal to [math] actually *reduces* the range of applicability of our stuff. Much better to let Hadoop / Mahout et al parallelize using fast and accurate piece parts that we can provide. If there are parallel algorithms that we are really dying to implement directly, I would rather see that done in a way that encapsulates and enables externalization of the thread management. > > * staying at Java 6/7 does not block users to use math in a Java 8 > environment if wanted +1 - the examples I have seen thus far are all things that could be done fairly easily with client code. I know we don't all agree with this, but I think the biggest service we can provide to our user base is good, tested, supported implementations of standard algorithms. I wish we could find a way to focus more on that and less on fiddling with the API or language features. Phil > > just my 2cents > > Thomas > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
