commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Carman <ja...@carmanconsulting.com>
Subject Re: [Math] Java version (Was: [MATH] Jenkins build)
Date Fri, 16 Jan 2015 12:42:11 GMT
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.steitz@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message