So, for places where you want to make use of streams, make your API take a Stream<T> rather than a Collection<T> or whatever, and require the user to choose whether to call parallelStream() or stream().
On Thu, Jan 15, 2015 at 5:41 PM, Phil Steitz <phil.ste...@gmail.com> wrote: > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
