Re: [Math] Java version

[Phil Steitz]

On 1/16/15 2:09 AM, Thomas Neidhart wrote:
> On 01/16/2015 01:30 AM, Gilles wrote:
>> On Thu, 15 Jan 2015 15:41:11 -0700, Phil Steitz 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
>> Sure.
>> Not so long ago, some people were claiming that nothing beats
>> programming in "assembly" language.
>>
>>> +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
>> Hard work / easy work.  Yes and no.  It depends on the motivation
>> of the contributor. Or we have to (re)define clearly the scope of
>> CM, and start some serious clean-up.
>> It's not all black or white; I'm quite convinced that it's better
>> to handle multi-threading externally when the core computation is
>> sequential.  But CM already contains algorithms that are inherently
>> parallel (a.o. genetic algorithms) and improvement in those areas
>> would undoubtedly benefit from (internal) parallel processing.
> I think the better approach is to support external parallelization
> rather than trying to do it yourself. From a user POV, I would be scared
> to use a library that does some kind of parallelization internally which
> I can not control.

+1
>
> Some recent examples show how it can be done better: there were some
> requests to make some of the statistics related classes map/reducable so
> that they can be used in Java 8 parallel streams.

+1 - mostly done.
>
> @genetic algorithms: there are far more better libraries out there for
> this area and the support we have in math is really very simplistic. You
> can basically do just a few demo examples with it and I am more in favor
> to deprecate the package.

Agreed there is better stuff out there, but I like the structure of
what we have (weak as the capabilities may be).  I have often
thought about playing with replacing the GeneticAlgorithm and
Population implementations with M/R-capable things.  I bet this
could be done without changing our API at all - just using the
lower-level constructs in a distributed execution environment.  I
have not actually done this so am not sure it would work; but I
don't see why not.  This still leaves gaps in encoding, etc; but
those could be filled over time.  I would be -0 on deprecating the
package, partly because I am a user of it :)

Phil
>
>>> 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.
>> Examples?
> because not everybody wants a library to do parallel stuff internally.
> Just imagine math being used in a web-application deployed together with
> many other applications. It is clearly not an option that one
> application might take over most/all of the available processors.
>
>>>  Much better to let Hadoop / Mahout et
>>> al parallelize using fast and accurate piece parts that we can
>>> provide.
>> Do they really do that?
>> [Or do they implement their own algorithms knowing that they must
>> be thread-safe (which is something we don't focus a lot on).]
> I guess they have mainly their own algorithms, but there are examples of
> our stuff being used (using the map/reduce paradigm).
>
>>>  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.
> +1, I have the impressions that they more we try to *optimize* an API we
> 

Re: [Math] Java version

[Emmanuel Bourg]

Le 16/01/2015 23:24, Ben McCann a écrit :
> I vote Java 7. We haven't been able to upgrade all our infrastructure to
> Java 8 yet because of a few issues. One of which could be fixed by someone
> from Commons Dev cutting a new release of BCEL. The last one got voted
> down, but I have a patch for the issues that blocked the release here:
> https://issues.apache.org/jira/browse/BCEL-186

Ben I think we understood at this point that you care deeply about BCEL
6.0, no need to reassert it in every message :)

Emmanuel Bourg


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

Re: [Math] Java version

[Ben McCann]

I vote Java 7. We haven't been able to upgrade all our infrastructure to
Java 8 yet because of a few issues. One of which could be fixed by someone
from Commons Dev cutting a new release of BCEL. The last one got voted
down, but I have a patch for the issues that blocked the release here:
https://issues.apache.org/jira/browse/BCEL-186

On Fri, Jan 16, 2015 at 2:13 PM, Ole Ersoy  wrote:

>
> On 01/16/2015 09:08 AM, Gilles wrote:
>
>> On Fri, 16 Jan 2015 15:16:16 +0100, Emmanuel Bourg wrote:
>>
>>> Le 16/01/2015 13:20, Gilles a écrit :
>>>
>>>  I'm interested to know more about this.
 Where can I find information?  Do you have links?

>>>
>>> Sure, Andrew Haley from Red Hat announced [1] two years ago that OpenJDK
>>> 6 would still be supported, and we can expect the same support for
>>> OpenJDK 7 in the future.
>>>
>>> Also the installation stats [2] for Debian show that OpenJDK 6 is still
>>> strong, about twice OpenJDK 7. And on Ubuntu [3] it's a 10x factor. So
>>> two years after the official EOL of Java 6 it's far from dead on the
>>> server side.
>>>
>>> Emmanuel Bourg
>>>
>>>
>>> [1] http://mail.openjdk.java.net/pipermail/jdk6-dev/2013-March/
>>> 002890.html
>>>
>>
>> Any more recent updates on the "hopes" mentioned there?
>>
>>  [2]
>>>
>>> https://qa.debian.org/popcon-graph.php?packages=sun-java6-
>>> jre+openjdk-6-jre+openjdk-7-jre+openjdk-8-jre&show_
>>> installed=on&want_legend=on&want_ticks=on&from_date=&to_
>>> date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1
>>>
>>
>> Nice; thanks.
>> Did you notice how the global picture seems to change when "jdk" replaces
>> "jre" in the request?
>> [Not counting the yet insignificant figures for Java 8, but if the trend
>> will be similar...]
>>
>>  [3] http://popcon.ubuntu.com/by_inst
>>>
>>
>> Interesting:
>> 193 votes for "libcommons-math-java"
>>   0 vote  for "libcommons-math3-java"
>>
>> What would one conclude from that?
>>
> One of the issues with linux repositories is that some, for example
> Fedora, have a policy that only one version of a library is allowed in the
> distribution.  So if it's easier to stick with "libcommons-math-java",
> because it does the job, and is already packaged, then that's what the
> packagers are going to want to do.
>
> I suspect most java developers would pull in their own version of math.
>
> Ole
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
about.me/benmccann

Re: [Math] Java version

[Ole Ersoy]

On 01/16/2015 09:08 AM, Gilles wrote:

On Fri, 16 Jan 2015 15:16:16 +0100, Emmanuel Bourg wrote:

Le 16/01/2015 13:20, Gilles a écrit :


I'm interested to know more about this.
Where can I find information?  Do you have links?


Sure, Andrew Haley from Red Hat announced [1] two years ago that OpenJDK
6 would still be supported, and we can expect the same support for
OpenJDK 7 in the future.

Also the installation stats [2] for Debian show that OpenJDK 6 is still
strong, about twice OpenJDK 7. And on Ubuntu [3] it's a 10x factor. So
two years after the official EOL of Java 6 it's far from dead on the
server side.

Emmanuel Bourg


[1] http://mail.openjdk.java.net/pipermail/jdk6-dev/2013-March/002890.html


Any more recent updates on the "hopes" mentioned there?


[2]

https://qa.debian.org/popcon-graph.php?packages=sun-java6-jre+openjdk-6-jre+openjdk-7-jre+openjdk-8-jre&show_installed=on&want_legend=on&want_ticks=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1


Nice; thanks.
Did you notice how the global picture seems to change when "jdk" replaces
"jre" in the request?
[Not counting the yet insignificant figures for Java 8, but if the trend
will be similar...]


[3] http://popcon.ubuntu.com/by_inst


Interesting:
193 votes for "libcommons-math-java"
  0 vote  for "libcommons-math3-java"

What would one conclude from that?

One of the issues with linux repositories is that some, for example Fedora, have a policy 
that only one version of a library is allowed in the distribution.  So if it's easier to 
stick with "libcommons-math-java", because it does the job, and is already 
packaged, then that's what the packagers are going to want to do.

I suspect most java developers would pull in their own version of math.

Ole


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

Re: [Math] Java version

[Ole Ersoy]

On 01/16/2015 03:09 AM, Thomas Neidhart wrote:

On 01/16/2015 01:30 AM, Gilles wrote:

On Thu, 15 Jan 2015 15:41:11 -0700, Phil Steitz 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

Sure.
Not so long ago, some people were claiming that nothing beats
programming in "assembly" language.


+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

Hard work / easy work.  Yes and no.  It depends on the motivation
of the contributor. Or we have to (re)define clearly the scope of
CM, and start some serious clean-up.
It's not all black or white; I'm quite convinced that it's better
to handle multi-threading externally when the core computation is
sequential.  But CM already contains algorithms that are inherently
parallel (a.o. genetic algorithms) and improvement in those areas
would undoubtedly benefit from (internal) parallel processing.

I think the better approach is to support external parallelization
rather than trying to do it yourself. From a user POV, I would be scared
to use a library that does some kind of parallelization internally which
I can not control.

Some recent examples show how it can be done better: there were some
requests to make some of the statistics related classes map/reducable so
that they can be used in Java 8 parallel streams.

@genetic algorithms: there are far more better libraries out there for
this area and the support we have in math is really very simplistic. You
can basically do just a few demo examples with it and I am more in favor
to deprecate the package.


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.

A year ago yes.  These days it's simple to create a docker container that wraps 
a Java service that can be deployed anywhere and scaled that it's really 
attractive to just have access to fast classes that are decoupled from a 
massive framework.

Also the Stream API takes care of the spawning.  The number of threads is 
initialized to the number of cores.

|ForkJoinPool  commonPool  =  ForkJoinPool.commonPool();
System.out.println(commonPool.getParallelism()); // 3

We can increase or decrease the number of cores available by setting:
|
||-Djava.util.concurrent.ForkJoinPool.common.parallelism=5|


|



Examples?

because not everybody wants a library to do parallel stuff internally.
Just imagine math being used in a web-application deployed together with
many other applications. It is clearly not an option that one
application might take over most/all of the available processors.

So if we have a webapp that has the potential to do this deploy it in it's own 
docker container on it's own subdomain.  Spring Boot for example makes it 
simple to generate a jar that is executable and contains the server(Tomcat, 
undertow, jetty, etc.), that can then be dockerized.

I was sitting next to the founder of meetup.io at starbucks the other day, and 
he deployed a server to a new subdomain in 20 seconds using dnsimple and 
digitalocean, at the cost of 10 cents an hour.

Incidentally what he wants for each app is speed and simple code.




  Much better to let Hadoop / Mahout et
al parallelize using fast and accurate piece parts that we can
provide.

Do they really do that?
[Or do they implement their own algorithms knowing that they must
be thread-safe (which is something we don't focus a lot on).]

I guess they have mainly their own algorithms, but there are examples of
our stuff being used (using the map/reduce paradigm).


  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.

It's just so nice to be able to use the other features that come with Java 8 
right out of the box though, and lets face,
we all take a step back and smile when we cut down a few lines of code, or 
Thingy runs 10% faster :).


  * staying at Java 6/7 does not block users to use math in a Java 8
environmen

Re: [Math] Java version

[Emmanuel Bourg]

Le 16/01/2015 16:08, Gilles a écrit :

> Any more recent updates on the "hopes" mentioned there?

None that I'm aware of. I expect one when the end of public updates is
reached for Java 7.


> Did you notice how the global picture seems to change when "jdk" replaces
> "jre" in the request?

I guess developpers are upgrading sooner than users and prod environments.


> Interesting:
> 193 votes for "libcommons-math-java"
>   0 vote  for "libcommons-math3-java"
> 
> What would one conclude from that?

This means that no package in Debian depends on commons-math3 yet.

Emmanuel Bourg


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

Re: [Math] Java version

[Gilles]

On Fri, 16 Jan 2015 15:16:16 +0100, Emmanuel Bourg wrote:

Le 16/01/2015 13:20, Gilles a écrit :


I'm interested to know more about this.
Where can I find information?  Do you have links?


Sure, Andrew Haley from Red Hat announced [1] two years ago that 
OpenJDK

6 would still be supported, and we can expect the same support for
OpenJDK 7 in the future.

Also the installation stats [2] for Debian show that OpenJDK 6 is 
still
strong, about twice OpenJDK 7. And on Ubuntu [3] it's a 10x factor. 
So

two years after the official EOL of Java 6 it's far from dead on the
server side.

Emmanuel Bourg


[1] 
http://mail.openjdk.java.net/pipermail/jdk6-dev/2013-March/002890.html


Any more recent updates on the "hopes" mentioned there?


[2]

https://qa.debian.org/popcon-graph.php?packages=sun-java6-jre+openjdk-6-jre+openjdk-7-jre+openjdk-8-jre&show_installed=on&want_legend=on&want_ticks=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1


Nice; thanks.
Did you notice how the global picture seems to change when "jdk" 
replaces

"jre" in the request?
[Not counting the yet insignificant figures for Java 8, but if the 
trend

will be similar...]


[3] http://popcon.ubuntu.com/by_inst


Interesting:
193 votes for "libcommons-math-java"
  0 vote  for "libcommons-math3-java"

What would one conclude from that?


Gilles


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

Re: [Math] Java version

[Gilles]

On Fri, 16 Jan 2015 10:09:02 +0100, Thomas Neidhart wrote:

On 01/16/2015 01:30 AM, Gilles wrote:

On Thu, 15 Jan 2015 15:41:11 -0700, Phil Steitz 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


Sure.
Not so long ago, some people were claiming that nothing beats
programming in "assembly" language.


+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


Hard work / easy work.  Yes and no.  It depends on the motivation
of the contributor. Or we have to (re)define clearly the scope of
CM, and start some serious clean-up.
It's not all black or white; I'm quite convinced that it's better
to handle multi-threading externally when the core computation is
sequential.  But CM already contains algorithms that are inherently
parallel (a.o. genetic algorithms) and improvement in those areas
would undoubtedly benefit from (internal) parallel processing.


I think the better approach is to support external parallelization
rather than trying to do it yourself. From a user POV, I would be 
scared
to use a library that does some kind of parallelization internally 
which

I can not control.

Some recent examples show how it can be done better: there were some
requests to make some of the statistics related classes map/reducable 
so

that they can be used in Java 8 parallel streams.

@genetic algorithms: there are far more better libraries out there 
for
this area and the support we have in math is really very simplistic. 
You
can basically do just a few demo examples with it and I am more in 
favor

to deprecate the package.


I pointed that out quite some time ago, but the deprecation idea was
outwardly rejected. [And further work was done on the package.]
This is IMO a major problem with CM: too many things are kept even
though there are no known users.
No user = no real-world testing = no improvement


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.


Examples?


because not everybody wants a library to do parallel stuff 
internally.
Just imagine math being used in a web-application deployed together 
with

many other applications. It is clearly not an option that one
application might take over most/all of the available processors.


I agree, but this a practical problem.
Is there a inherent impossibility to find a solution?


 Much better to let Hadoop / Mahout et
al parallelize using fast and accurate piece parts that we can
provide.


Do they really do that?
[Or do they implement their own algorithms knowing that they must
be thread-safe (which is something we don't focus a lot on).]


I guess they have mainly their own algorithms, but there are examples 
of

our stuff being used (using the map/reduce paradigm).


OK. Then, I would conclude that implementing the correct interface(s)
to allow this usage _must_ be among the top (yet unwritten) rules
for new contributions to, and refactoring of, CM.




 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.


+1, I have the impressions that they more we try to *optimize* an API 
we

end up with an inferior solution (with a few exceptions).

There is too much discussion about API design. We should have our 
best

practices and use them to implement rock-solid algorithms, which is
already difficult enough.


I agree.


In the end it does not matter so much if you
have a fluent API or whatever, as l

Re: [Math] Java version

[Silviu Burcea]

Maybe nobody is interested to upgrade the Java version if they are not
forced to. If nobody force them, then CM will have to support Java 6 even
for 5.0 release. The sooner we drop support for older version, the better.
I'd say that current and current - 1 versions(i.e. 7 and 8) are more than
enough.

On Fri, Jan 16, 2015 at 4:16 PM, Emmanuel Bourg  wrote:

> Le 16/01/2015 13:20, Gilles a écrit :
>
> > I'm interested to know more about this.
> > Where can I find information?  Do you have links?
>
> Sure, Andrew Haley from Red Hat announced [1] two years ago that OpenJDK
> 6 would still be supported, and we can expect the same support for
> OpenJDK 7 in the future.
>
> Also the installation stats [2] for Debian show that OpenJDK 6 is still
> strong, about twice OpenJDK 7. And on Ubuntu [3] it's a 10x factor. So
> two years after the official EOL of Java 6 it's far from dead on the
> server side.
>
> Emmanuel Bourg
>
>
> [1] http://mail.openjdk.java.net/pipermail/jdk6-dev/2013-March/002890.html
> [2]
>
> https://qa.debian.org/popcon-graph.php?packages=sun-java6-jre+openjdk-6-jre+openjdk-7-jre+openjdk-8-jre&show_installed=on&want_legend=on&want_ticks=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1
> [3] http://popcon.ubuntu.com/by_inst
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
- OCPJP7 (90%)
- OCAJP7 (93%)
- Java and Big Data Enthusiast

Re: [Math] Java version

[Emmanuel Bourg]

Le 16/01/2015 13:20, Gilles a écrit :

> I'm interested to know more about this.
> Where can I find information?  Do you have links?

Sure, Andrew Haley from Red Hat announced [1] two years ago that OpenJDK
6 would still be supported, and we can expect the same support for
OpenJDK 7 in the future.

Also the installation stats [2] for Debian show that OpenJDK 6 is still
strong, about twice OpenJDK 7. And on Ubuntu [3] it's a 10x factor. So
two years after the official EOL of Java 6 it's far from dead on the
server side.

Emmanuel Bourg


[1] http://mail.openjdk.java.net/pipermail/jdk6-dev/2013-March/002890.html
[2]
https://qa.debian.org/popcon-graph.php?packages=sun-java6-jre+openjdk-6-jre+openjdk-7-jre+openjdk-8-jre&show_installed=on&want_legend=on&want_ticks=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1
[3] http://popcon.ubuntu.com/by_inst


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

Re: [Math] Java version (Was: [MATH] Jenkins build)

[James Carman]

So, for places where you want to make use of streams, make your API
take a Stream rather than a Collection 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  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

Re: [Math] Java version

[Gilles]

On Fri, 16 Jan 2015 11:13:07 +0100, Emmanuel Bourg wrote:

Le 15/01/2015 17:15, Gilles a écrit :

I wonder: Isn't the "end of public updates"[1] (scheduled on April 
of

this year for Java 7) somehow going to change that picture a lot?
If not, why?


That will not change much the current situation. Java 8 is already 
the

default JRE proposed on http://java.com since September 2014 and its
usage is increasing steadily on desktop computers (the stats on my
application are Java 8: 25%, Java 7: 55%, Java 6: 20%). But on 
servers

the transition is much slower, and the OpenJDK 7 used by the Linux
distributions will be supported for several years after the end of 
the

public updates.


I'm interested to know more about this.
Where can I find information?  Do you have links?

Thanks,
Gilles




Emmanuel Bourg




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

Re: [Math] Java version

[Emmanuel Bourg]

Le 15/01/2015 17:15, Gilles a écrit :

> I wonder: Isn't the "end of public updates"[1] (scheduled on April of
> this year for Java 7) somehow going to change that picture a lot?
> If not, why?

That will not change much the current situation. Java 8 is already the
default JRE proposed on http://java.com since September 2014 and its
usage is increasing steadily on desktop computers (the stats on my
application are Java 8: 25%, Java 7: 55%, Java 6: 20%). But on servers
the transition is much slower, and the OpenJDK 7 used by the Linux
distributions will be supported for several years after the end of the
public updates.

Emmanuel Bourg


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

Re: [Math] Java version

[Thomas Neidhart]

On 01/16/2015 01:30 AM, Gilles wrote:
> On Thu, 15 Jan 2015 15:41:11 -0700, Phil Steitz 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
> 
> Sure.
> Not so long ago, some people were claiming that nothing beats
> programming in "assembly" language.
> 
>> +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
> 
> Hard work / easy work.  Yes and no.  It depends on the motivation
> of the contributor. Or we have to (re)define clearly the scope of
> CM, and start some serious clean-up.
> It's not all black or white; I'm quite convinced that it's better
> to handle multi-threading externally when the core computation is
> sequential.  But CM already contains algorithms that are inherently
> parallel (a.o. genetic algorithms) and improvement in those areas
> would undoubtedly benefit from (internal) parallel processing.

I think the better approach is to support external parallelization
rather than trying to do it yourself. From a user POV, I would be scared
to use a library that does some kind of parallelization internally which
I can not control.

Some recent examples show how it can be done better: there were some
requests to make some of the statistics related classes map/reducable so
that they can be used in Java 8 parallel streams.

@genetic algorithms: there are far more better libraries out there for
this area and the support we have in math is really very simplistic. You
can basically do just a few demo examples with it and I am more in favor
to deprecate the package.

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

because not everybody wants a library to do parallel stuff internally.
Just imagine math being used in a web-application deployed together with
many other applications. It is clearly not an option that one
application might take over most/all of the available processors.

>>  Much better to let Hadoop / Mahout et
>> al parallelize using fast and accurate piece parts that we can
>> provide.
> 
> Do they really do that?
> [Or do they implement their own algorithms knowing that they must
> be thread-safe (which is something we don't focus a lot on).]

I guess they have mainly their own algorithms, but there are examples of
our stuff being used (using the map/reduce paradigm).

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

+1, I have the impressions that they more we try to *optimize* an API we
end up with an inferior solution (with a few exceptions).

There is too much discussion about API design. We should have our best
practices and use them to implement rock-solid algorithms, which is
already difficult enough. In the end it does not matter so much if you
have a fluent API or whatever, as long as it calculates the correct
result, and is easy to use, imho.

> The problem is that those discussions constantly mix considerations
> about contents, with political moves that do not necessarily match.
> For example, a statement about contents would be: CM only provides
> implementations of sequential mathematical algorithms.
> But recent political moves, like changing the version control system
> or advertizing "free for all" commit rights, aim at increasing the

Re: [Math] Java version

[Gilles]

On Thu, 15 Jan 2015 15:41:11 -0700, Phil Steitz 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


Sure.
Not so long ago, some people were claiming that nothing beats
programming in "assembly" language.


+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


Hard work / easy work.  Yes and no.  It depends on the motivation
of the contributor. Or we have to (re)define clearly the scope of
CM, and start some serious clean-up.
It's not all black or white; I'm quite convinced that it's better
to handle multi-threading externally when the core computation is
sequential.  But CM already contains algorithms that are inherently
parallel (a.o. genetic algorithms) and improvement in those areas
would undoubtedly benefit from (internal) parallel processing.



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.


Examples?


 Much better to let Hadoop / Mahout et
al parallelize using fast and accurate piece parts that we can
provide.


Do they really do that?
[Or do they implement their own algorithms knowing that they must
be thread-safe (which is something we don't focus a lot on).]


 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.


The problem is that those discussions constantly mix considerations
about contents, with political moves that do not necessarily match.
For example, a statement about contents would be: CM only provides
implementations of sequential mathematical algorithms.
But recent political moves, like changing the version control system
or advertizing "free for all" commit rights, aim at increasing the
contributor base.
What about those people interested in API fixing and new language
features?  You'll make them want to contribute to another project.
Now that Java is, at last, beginning to catch up with other
languages incomparably more widely used in the scientific community,
Commons Math is discussing how far behind it is going to lag!


Regards,
Gilles


Phil



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

Re: [Math] Java version (Was: [MATH] Jenkins build)

[Phil Steitz]

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

Re: [Math] Java version (Was: [MATH] Jenkins build)

[Ole Ersoy]

On 01/15/2015 03: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

  * 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

Creating thread safe classes / algorithms has traditionally been "Tricky".  
With Java 8 parallel streams processing concurrency is a lower hanging fruit.  For 
example (Taken from http://winterbe.com/posts/2014/07/31/java8-stream-tutorial-examples/):

|=

Integer  ageSum  =  persons
.parallelStream()
.reduce(0,
(sum,  p)  ->  {
System.out.format("accumulator: sum=%s; person=%s\n",  sum,  p);
return  sum  +=  p.age;
},
(sum1,  sum2)  ->  {
System.out.format("combiner: sum1=%s; sum2=%s\n",  sum1,  sum2);
return  sum1  +  sum2;
});

// accumulator: sum=0; person=Pamela
// accumulator: sum=0; person=David
// accumulator: sum=0; person=Max
// accumulator: sum=0; person=Peter
// combiner: sum1=18; sum2=23
// combiner: sum1=23; sum2=12
// combiner: sum1=41; sum2=35
|
|=

Less boilerplate, easier to read code, that's more efficient.  Java 8 
encourages making use of the fluid functional programming internally that
that the newer APIs aim to provide "Externally".
|

Cheers,
Ole

Re: [Math] Java version (Was: [MATH] Jenkins build)

[Thomas Neidhart]

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

 * 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

 * staying at Java 6/7 does not block users to use math in a Java 8
environment if wanted

just my 2cents

Thomas

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

Re: [Math] Java version

[Bruce A Johnson]

I’m very happily starting to use Java 8 and am making lots of use of JavaFX 
(not so relevant to Math), and lambdas and streams (playing around with a 
little numpy like interface to Math).
So, on the one hand I’m all for Java 8, but on the other hand there are things 
I’d rather see done for the Math 4 release and trying to update Math to use 
Java 8 features could slow the resolution of existing issues.  So I’d lean 
towards a release of Math 4 in the not to distant future that doesn’t rely on 
Java 8 features, and then a move towards Math 5 with careful thought as to how 
it could benefit from Java 8. 

Bruce



> On Jan 15, 2015, at 2:14 PM, Ole Ersoy  wrote:
> 
> How many of the mobile developers have to have a 4.0 release?  I suspect that 
> 90% would be fine using 3.4, and the remaining 10% can wire the results of 
> the calculation using alternative means such as a REST or Socket service.
> 
> Cheers,
> - Ole
> 
> 
> 
> On 01/15/2015 11:32 AM, venkatesha m wrote:
>> 
>> 
>> 
>> 
>> On Thursday, 15 January 2015 10:45 PM, Gilles  
>> wrote:
>> On Thu, 15 Jan 2015 12:05:27 -0500, Hank Grabowski wrote:
>>> You would think so, but Java 6 hasn't been updated since early 2013
>>> and is
>>> still a quarter or more of the installed Java base.  The support for
>>> highly
>>> scalable parallel operations that the new Java 8 language features
>>> get is
>>> very tempting though.  Could we have a Java 8 branch on the core
>>> library
>>> and release a CM for each of them until the vestigial versions are
>>> sufficiently low enough on the usage chain?  I know there are some
>>> versioning and release nightmares that could introduce but with the
>>> parallel functions maybe it would be worth it unlike the changes that
>>> 6 to
>>> 7 would give for the project.
>> Although the consensus would say "Java 7", but then we'd lose the newer
>> and even better (hopefully) facilities, and still be "old" when
>> everybody
>> will have change their phone already. ;-)
>> 
>> Would you be willing to volunteer with a concrete plan?
>> 
>> Best,
>> Gilles
>> 
>> 
>>> On Thu, Jan 15, 2015 at 11:15 AM, Gilles
>>> 
>>> wrote:
>>> 
 On Thu, 15 Jan 2015 07:52:11 -0500, Hank Grabowski wrote:
 
> Good call, Silviu!
> 
> The most recent version of their survey of Plumbr installations
> (823 in
> total) was May of last year, only a few months after Java 8 came
> out (link
> below).  At that time the break down was: Java 5 at 0.4%, Java 6 at
> 36%,
> Java 7 at 61% and Java 8 at 2.5%.  I'm still looking for more data
> on
> this,
> but Rebel Labs has a similar article (not broken down by version)
> that
> showed that 65% of development was on Java 7 by May of last year
> too. I
> doubt the balance was Java 8 at that point, so there must be a
> sizable
> Java
> 6 contingent still.
> 
> One other thing that came to mind with the new Java 8 features is
> how that
> is supported on Android.  As far as I can tell Android KitKat, as
> well as
> the latest release of the Android Studio and SDK Tools doesn't
> support
> Java
> 8 yet.  In fact, according to the Android development setup page
> versions
> between (and including) Gingerbread and KitKat require JDK 6, not
> 7.  I
> haven't coded Android recently to know whether it does work on JDK
> 7 or if
> is just a requirement but it is peculiar that the main instructions
> call
> for JDK 7 installation and then the footnote specifically tells
> developers
> to pull a different JDK version for those earlier platforms.  I
> can't tell
> where the Java 7 language features were added to Android before the
> current
> version, Lollipop.  I was surprised Lollipop wasn't on their
> dashboard but
> according to the AppBrain statistics it accounts for far less than
> 1% of
> the installed phones.  So best case scenario would be Jelly Bean
> supports
> 7
> (no indication that's true), which means 85% of Android devices
> would be
> covered if we set a Java 7 minimum.  Next best would be KitKat
> (more
> likely
> but not according to the install instructions) which means 39%.  As
> for
> Java 5, that was needed for pre-Gingerbread Android OS which
> accounts for
> 0.5% of the market.
> 
> I guess with all of that it's clear that Java 5 is unnecessarily
> being
> maintained at this point.  Both surveys of servers and Android show
> far
> less than 1% usage.  It seems Java 6 penetration may be still be
> pretty
> substantial, even conservatively at on the order of 25% (if Java 7
> and 8
> adoption picked up dramatically in 6 months after the surveys as I
> imagine
> it did to some extent).  So it seems the most reasonable
> conservative play
> would be to stick with Java 6, especially if we can confirm that
> bet

Re: [Math] Java version

[Ole Ersoy]

How many of the mobile developers have to have a 4.0 release?  I suspect that 
90% would be fine using 3.4, and the remaining 10% can wire the results of the 
calculation using alternative means such as a REST or Socket service.

Cheers,
- Ole



On 01/15/2015 11:32 AM, venkatesha m wrote:





On Thursday, 15 January 2015 10:45 PM, Gilles  
wrote:
On Thu, 15 Jan 2015 12:05:27 -0500, Hank Grabowski wrote:

You would think so, but Java 6 hasn't been updated since early 2013
and is
still a quarter or more of the installed Java base.  The support for
highly
scalable parallel operations that the new Java 8 language features
get is
very tempting though.  Could we have a Java 8 branch on the core
library
and release a CM for each of them until the vestigial versions are
sufficiently low enough on the usage chain?  I know there are some
versioning and release nightmares that could introduce but with the
parallel functions maybe it would be worth it unlike the changes that
6 to
7 would give for the project.

Although the consensus would say "Java 7", but then we'd lose the newer
and even better (hopefully) facilities, and still be "old" when
everybody
will have change their phone already. ;-)

Would you be willing to volunteer with a concrete plan?

Best,
Gilles



On Thu, Jan 15, 2015 at 11:15 AM, Gilles

wrote:


On Thu, 15 Jan 2015 07:52:11 -0500, Hank Grabowski wrote:


Good call, Silviu!

The most recent version of their survey of Plumbr installations
(823 in
total) was May of last year, only a few months after Java 8 came
out (link
below).  At that time the break down was: Java 5 at 0.4%, Java 6 at
36%,
Java 7 at 61% and Java 8 at 2.5%.  I'm still looking for more data
on
this,
but Rebel Labs has a similar article (not broken down by version)
that
showed that 65% of development was on Java 7 by May of last year
too. I
doubt the balance was Java 8 at that point, so there must be a
sizable
Java
6 contingent still.

One other thing that came to mind with the new Java 8 features is
how that
is supported on Android.  As far as I can tell Android KitKat, as
well as
the latest release of the Android Studio and SDK Tools doesn't
support
Java
8 yet.  In fact, according to the Android development setup page
versions
between (and including) Gingerbread and KitKat require JDK 6, not
7.  I
haven't coded Android recently to know whether it does work on JDK
7 or if
is just a requirement but it is peculiar that the main instructions
call
for JDK 7 installation and then the footnote specifically tells
developers
to pull a different JDK version for those earlier platforms.  I
can't tell
where the Java 7 language features were added to Android before the
current
version, Lollipop.  I was surprised Lollipop wasn't on their
dashboard but
according to the AppBrain statistics it accounts for far less than
1% of
the installed phones.  So best case scenario would be Jelly Bean
supports
7
(no indication that's true), which means 85% of Android devices
would be
covered if we set a Java 7 minimum.  Next best would be KitKat
(more
likely
but not according to the install instructions) which means 39%.  As
for
Java 5, that was needed for pre-Gingerbread Android OS which
accounts for
0.5% of the market.

I guess with all of that it's clear that Java 5 is unnecessarily
being
maintained at this point.  Both surveys of servers and Android show
far
less than 1% usage.  It seems Java 6 penetration may be still be
pretty
substantial, even conservatively at on the order of 25% (if Java 7
and 8
adoption picked up dramatically in 6 months after the surveys as I
imagine
it did to some extent).  So it seems the most reasonable
conservative play
would be to stick with Java 6, especially if we can confirm that
between
half to 85% of Android devices can't use Java 7 language features.
A more
aggressive play would be to set a requirement for Java 7.  Setting
the
minimum at Java 8 at this time seems overly aggressive at this time
though.

https://plumbr.eu/blog/most-popular-java-environments-in-2014

http://pages.zeroturnaround.com/Java-Tools-Technologies.html

http://source.android.com/source/initializing.html

https://developer.android.com/about/dashboards/index.html

http://www.appbrain.com/stats/top-android-sdk-versions


I wonder: Isn't the "end of public updates"[1] (scheduled on April
of
this year for Java 7) somehow going to change that picture a lot?
If not, why?


Regards,
Gilles

[1] http://www.oracle.com/technetwork/java/eol-135779.html





On Wed, Jan 14, 2015 at 11:20 PM, Silviu Burcea <
silviuburcea...@gmail.com>
wrote:

  I think Rebel Labs or Plumbr have some metrics about JDK usage.

On Wed, Jan 14, 2015 at 10:21 PM, Hank Grabowski <
h...@applieddefense.com>
wrote:


Java 8 has only been out for less than a year.  There is still a

sizable

percentage of groups that have not converted up to Java 8 for

myriad

reasons.  While I was surprised that we are requiring backwards
compatibility with the ten year old Java 5 I think jumping all

Re: [Math] Java version

[Andy Seaborne]

On 15/01/15 16:15, Gilles wrote:

On Thu, 15 Jan 2015 07:52:11 -0500, Hank Grabowski wrote:

Good call, Silviu!

The most recent version of their survey of Plumbr installations (823 in
total) was May of last year, only a few months after Java 8 came out
(link
below).  At that time the break down was: Java 5 at 0.4%, Java 6 at 36%,
Java 7 at 61% and Java 8 at 2.5%.  I'm still looking for more data on
this,
but Rebel Labs has a similar article (not broken down by version) that
showed that 65% of development was on Java 7 by May of last year too. I
doubt the balance was Java 8 at that point, so there must be a sizable
Java
6 contingent still.

One other thing that came to mind with the new Java 8 features is how
that
is supported on Android.  As far as I can tell Android KitKat, as well as
the latest release of the Android Studio and SDK Tools doesn't support
Java
8 yet.  In fact, according to the Android development setup page versions
between (and including) Gingerbread and KitKat require JDK 6, not 7. I
haven't coded Android recently to know whether it does work on JDK 7
or if
is just a requirement but it is peculiar that the main instructions call
for JDK 7 installation and then the footnote specifically tells
developers
to pull a different JDK version for those earlier platforms.  I can't
tell
where the Java 7 language features were added to Android before the
current
version, Lollipop.  I was surprised Lollipop wasn't on their dashboard
but
according to the AppBrain statistics it accounts for far less than 1% of
the installed phones.  So best case scenario would be Jelly Bean
supports 7
(no indication that's true), which means 85% of Android devices would be
covered if we set a Java 7 minimum.  Next best would be KitKat (more
likely
but not according to the install instructions) which means 39%.  As for
Java 5, that was needed for pre-Gingerbread Android OS which accounts for
0.5% of the market.

I guess with all of that it's clear that Java 5 is unnecessarily being
maintained at this point.  Both surveys of servers and Android show far
less than 1% usage.  It seems Java 6 penetration may be still be pretty
substantial, even conservatively at on the order of 25% (if Java 7 and 8
adoption picked up dramatically in 6 months after the surveys as I
imagine
it did to some extent).  So it seems the most reasonable conservative
play
would be to stick with Java 6, especially if we can confirm that between
half to 85% of Android devices can't use Java 7 language features.  A
more
aggressive play would be to set a requirement for Java 7.  Setting the
minimum at Java 8 at this time seems overly aggressive at this time
though.

https://plumbr.eu/blog/most-popular-java-environments-in-2014

http://pages.zeroturnaround.com/Java-Tools-Technologies.html

http://source.android.com/source/initializing.html

https://developer.android.com/about/dashboards/index.html

http://www.appbrain.com/stats/top-android-sdk-versions


I wonder: Isn't the "end of public updates"[1] (scheduled on April of
this year for Java 7) somehow going to change that picture a lot?
If not, why?


Regards,
Gilles

[1] http://www.oracle.com/technetwork/java/eol-135779.html


And for other JVMs:

http://www.ibm.com/developerworks/java/jdk/lifecycle/

java7 is still current -- "only" beta java8 currently AFAIK.

My experience is that there is a significant "why change what's not 
broken" effect (stable systems don't upgrade software, whether 
dependencies or java) so it is not only how much Java Nbut also how many of those users will update software that is depending 
on it.


There is no single right answer - best of luck.

Andy









On Wed, Jan 14, 2015 at 11:20 PM, Silviu Burcea

wrote:


I think Rebel Labs or Plumbr have some metrics about JDK usage.

On Wed, Jan 14, 2015 at 10:21 PM, Hank Grabowski

wrote:

> Java 8 has only been out for less than a year.  There is still a
sizable
> percentage of groups that have not converted up to Java 8 for myriad
> reasons.  While I was surprised that we are requiring backwards
> compatibility with the ten year old Java 5 I think jumping all the
way to
> requiring Java 8 may be a bit too much of a stretch.  I would vote
for a
> minimum required version of Java 7 with the ability to run in Java
8.  I
> wish I could find metrics to quantify the penetration of each of the
JDKs,
> but my gut says Java 7 would a reasonable cutoff.
>
> On Tue, Jan 13, 2015 at 8:31 PM, Gilles 
> wrote:
>
> > Raising this issue once again.
> >>> Are we going to upgrade the requirement for the next major
release?
> >>>
> >>>  [ ] Java 5
> >>>  [ ] Java 6
> >>>  [ ] Java 7
> >>>  [ ] Java 8
> >>>  [ ] Java 9
> >>>
> >>
> > Counts up to now:
> >
> > Java 7  -> 2
> > Java 7 or 8 -> 2
> > Java 8  -> 2
> >
> > Any more opionions?
> >
> > Gilles




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

Re: [Math] Java version

[venkatesha m]

On Thursday, 15 January 2015 10:45 PM, Gilles  
wrote:
On Thu, 15 Jan 2015 12:05:27 -0500, Hank Grabowski wrote:
> You would think so, but Java 6 hasn't been updated since early 2013 
> and is
> still a quarter or more of the installed Java base.  The support for 
> highly
> scalable parallel operations that the new Java 8 language features 
> get is
> very tempting though.  Could we have a Java 8 branch on the core 
> library
> and release a CM for each of them until the vestigial versions are
> sufficiently low enough on the usage chain?  I know there are some
> versioning and release nightmares that could introduce but with the
> parallel functions maybe it would be worth it unlike the changes that 
> 6 to
> 7 would give for the project.

Although the consensus would say "Java 7", but then we'd lose the newer
and even better (hopefully) facilities, and still be "old" when 
everybody
will have change their phone already. ;-)

Would you be willing to volunteer with a concrete plan?

Best,
Gilles


>
> On Thu, Jan 15, 2015 at 11:15 AM, Gilles 
> 
> wrote:
>
>> On Thu, 15 Jan 2015 07:52:11 -0500, Hank Grabowski wrote:
>>
>>> Good call, Silviu!
>>>
>>> The most recent version of their survey of Plumbr installations 
>>> (823 in
>>> total) was May of last year, only a few months after Java 8 came 
>>> out (link
>>> below).  At that time the break down was: Java 5 at 0.4%, Java 6 at 
>>> 36%,
>>> Java 7 at 61% and Java 8 at 2.5%.  I'm still looking for more data 
>>> on
>>> this,
>>> but Rebel Labs has a similar article (not broken down by version) 
>>> that
>>> showed that 65% of development was on Java 7 by May of last year 
>>> too. I
>>> doubt the balance was Java 8 at that point, so there must be a 
>>> sizable
>>> Java
>>> 6 contingent still.
>>>
>>> One other thing that came to mind with the new Java 8 features is 
>>> how that
>>> is supported on Android.  As far as I can tell Android KitKat, as 
>>> well as
>>> the latest release of the Android Studio and SDK Tools doesn't 
>>> support
>>> Java
>>> 8 yet.  In fact, according to the Android development setup page 
>>> versions
>>> between (and including) Gingerbread and KitKat require JDK 6, not 
>>> 7.  I
>>> haven't coded Android recently to know whether it does work on JDK 
>>> 7 or if
>>> is just a requirement but it is peculiar that the main instructions 
>>> call
>>> for JDK 7 installation and then the footnote specifically tells 
>>> developers
>>> to pull a different JDK version for those earlier platforms.  I 
>>> can't tell
>>> where the Java 7 language features were added to Android before the
>>> current
>>> version, Lollipop.  I was surprised Lollipop wasn't on their 
>>> dashboard but
>>> according to the AppBrain statistics it accounts for far less than 
>>> 1% of
>>> the installed phones.  So best case scenario would be Jelly Bean 
>>> supports
>>> 7
>>> (no indication that's true), which means 85% of Android devices 
>>> would be
>>> covered if we set a Java 7 minimum.  Next best would be KitKat 
>>> (more
>>> likely
>>> but not according to the install instructions) which means 39%.  As 
>>> for
>>> Java 5, that was needed for pre-Gingerbread Android OS which 
>>> accounts for
>>> 0.5% of the market.
>>>
>>> I guess with all of that it's clear that Java 5 is unnecessarily 
>>> being
>>> maintained at this point.  Both surveys of servers and Android show 
>>> far
>>> less than 1% usage.  It seems Java 6 penetration may be still be 
>>> pretty
>>> substantial, even conservatively at on the order of 25% (if Java 7 
>>> and 8
>>> adoption picked up dramatically in 6 months after the surveys as I 
>>> imagine
>>> it did to some extent).  So it seems the most reasonable 
>>> conservative play
>>> would be to stick with Java 6, especially if we can confirm that 
>>> between
>>> half to 85% of Android devices can't use Java 7 language features.  
>>> A more
>>> aggressive play would be to set a requirement for Java 7.  Setting 
>>> the
>>> minimum at Java 8 at this time seems overly aggressive at this time
>>> though.
>>>
>>> https://plumbr.eu/blog/most-popular-java-environments-in-2014
>>>
>>> http://pages.zeroturnaround.com/Java-Tools-Technologies.html
>>>
>>> http://source.android.com/source/initializing.html
>>>
>>> https://developer.android.com/about/dashboards/index.html
>>>
>>> http://www.appbrain.com/stats/top-android-sdk-versions
>>>
>>
>> I wonder: Isn't the "end of public updates"[1] (scheduled on April 
>> of
>> this year for Java 7) somehow going to change that picture a lot?
>> If not, why?
>>
>>
>> Regards,
>> Gilles
>>
>> [1] http://www.oracle.com/technetwork/java/eol-135779.html
>>
>>
>>
>>
>>> On Wed, Jan 14, 2015 at 11:20 PM, Silviu Burcea <
>>> silviuburcea...@gmail.com>
>>> wrote:
>>>
>>>  I think Rebel Labs or Plumbr have some metrics about JDK usage.

 On Wed, Jan 14, 2015 at 10:21 PM, Hank Grabowski <
 h...@applieddefense.com>
 wrote:

 > Java 8 has only been out for less than a year.  Ther

Re: [Math] Java version

[Hank Grabowski]

As much as I would like to I'm very new to the Apache development
universe.  I've actually been involved through one release cycle and only
as a contributor.  I wouldn't mind working with a more seasoned person
batting around ideas offline to then present to the group though.

On Thu, Jan 15, 2015 at 12:14 PM, Gilles 
wrote:

> On Thu, 15 Jan 2015 12:05:27 -0500, Hank Grabowski wrote:
>
>> You would think so, but Java 6 hasn't been updated since early 2013 and is
>> still a quarter or more of the installed Java base.  The support for
>> highly
>> scalable parallel operations that the new Java 8 language features get is
>> very tempting though.  Could we have a Java 8 branch on the core library
>> and release a CM for each of them until the vestigial versions are
>> sufficiently low enough on the usage chain?  I know there are some
>> versioning and release nightmares that could introduce but with the
>> parallel functions maybe it would be worth it unlike the changes that 6 to
>> 7 would give for the project.
>>
>
> Although the consensus would say "Java 7", but then we'd lose the newer
> and even better (hopefully) facilities, and still be "old" when everybody
> will have change their phone already. ;-)
>
> Would you be willing to volunteer with a concrete plan?
>
> Best,
> Gilles
>
>
>
>
>> On Thu, Jan 15, 2015 at 11:15 AM, Gilles 
>> wrote:
>>
>>  On Thu, 15 Jan 2015 07:52:11 -0500, Hank Grabowski wrote:
>>>
>>>  Good call, Silviu!

 The most recent version of their survey of Plumbr installations (823 in
 total) was May of last year, only a few months after Java 8 came out
 (link
 below).  At that time the break down was: Java 5 at 0.4%, Java 6 at 36%,
 Java 7 at 61% and Java 8 at 2.5%.  I'm still looking for more data on
 this,
 but Rebel Labs has a similar article (not broken down by version) that
 showed that 65% of development was on Java 7 by May of last year too. I
 doubt the balance was Java 8 at that point, so there must be a sizable
 Java
 6 contingent still.

 One other thing that came to mind with the new Java 8 features is how
 that
 is supported on Android.  As far as I can tell Android KitKat, as well
 as
 the latest release of the Android Studio and SDK Tools doesn't support
 Java
 8 yet.  In fact, according to the Android development setup page
 versions
 between (and including) Gingerbread and KitKat require JDK 6, not 7.  I
 haven't coded Android recently to know whether it does work on JDK 7 or
 if
 is just a requirement but it is peculiar that the main instructions call
 for JDK 7 installation and then the footnote specifically tells
 developers
 to pull a different JDK version for those earlier platforms.  I can't
 tell
 where the Java 7 language features were added to Android before the
 current
 version, Lollipop.  I was surprised Lollipop wasn't on their dashboard
 but
 according to the AppBrain statistics it accounts for far less than 1% of
 the installed phones.  So best case scenario would be Jelly Bean
 supports
 7
 (no indication that's true), which means 85% of Android devices would be
 covered if we set a Java 7 minimum.  Next best would be KitKat (more
 likely
 but not according to the install instructions) which means 39%.  As for
 Java 5, that was needed for pre-Gingerbread Android OS which accounts
 for
 0.5% of the market.

 I guess with all of that it's clear that Java 5 is unnecessarily being
 maintained at this point.  Both surveys of servers and Android show far
 less than 1% usage.  It seems Java 6 penetration may be still be pretty
 substantial, even conservatively at on the order of 25% (if Java 7 and 8
 adoption picked up dramatically in 6 months after the surveys as I
 imagine
 it did to some extent).  So it seems the most reasonable conservative
 play
 would be to stick with Java 6, especially if we can confirm that between
 half to 85% of Android devices can't use Java 7 language features.  A
 more
 aggressive play would be to set a requirement for Java 7.  Setting the
 minimum at Java 8 at this time seems overly aggressive at this time
 though.

 https://plumbr.eu/blog/most-popular-java-environments-in-2014

 http://pages.zeroturnaround.com/Java-Tools-Technologies.html

 http://source.android.com/source/initializing.html

 https://developer.android.com/about/dashboards/index.html

 http://www.appbrain.com/stats/top-android-sdk-versions


>>> I wonder: Isn't the "end of public updates"[1] (scheduled on April of
>>> this year for Java 7) somehow going to change that picture a lot?
>>> If not, why?
>>>
>>>
>>> Regards,
>>> Gilles
>>>
>>> [1] http://www.oracle.com/technetwork/java/eol-135779.html
>>>
>>>
>>>
>>>
>>>  On Wed, Jan 14, 2015 at 11:20 PM, Silviu Burcea <
 silviuburc

Re: [Math] Java version

[Gilles]

On Thu, 15 Jan 2015 12:05:27 -0500, Hank Grabowski wrote:
You would think so, but Java 6 hasn't been updated since early 2013 
and is
still a quarter or more of the installed Java base.  The support for 
highly
scalable parallel operations that the new Java 8 language features 
get is
very tempting though.  Could we have a Java 8 branch on the core 
library

and release a CM for each of them until the vestigial versions are
sufficiently low enough on the usage chain?  I know there are some
versioning and release nightmares that could introduce but with the
parallel functions maybe it would be worth it unlike the changes that 
6 to

7 would give for the project.


Although the consensus would say "Java 7", but then we'd lose the newer
and even better (hopefully) facilities, and still be "old" when 
everybody

will have change their phone already. ;-)

Would you be willing to volunteer with a concrete plan?

Best,
Gilles




On Thu, Jan 15, 2015 at 11:15 AM, Gilles 


wrote:


On Thu, 15 Jan 2015 07:52:11 -0500, Hank Grabowski wrote:


Good call, Silviu!

The most recent version of their survey of Plumbr installations 
(823 in
total) was May of last year, only a few months after Java 8 came 
out (link
below).  At that time the break down was: Java 5 at 0.4%, Java 6 at 
36%,
Java 7 at 61% and Java 8 at 2.5%.  I'm still looking for more data 
on

this,
but Rebel Labs has a similar article (not broken down by version) 
that
showed that 65% of development was on Java 7 by May of last year 
too. I
doubt the balance was Java 8 at that point, so there must be a 
sizable

Java
6 contingent still.

One other thing that came to mind with the new Java 8 features is 
how that
is supported on Android.  As far as I can tell Android KitKat, as 
well as
the latest release of the Android Studio and SDK Tools doesn't 
support

Java
8 yet.  In fact, according to the Android development setup page 
versions
between (and including) Gingerbread and KitKat require JDK 6, not 
7.  I
haven't coded Android recently to know whether it does work on JDK 
7 or if
is just a requirement but it is peculiar that the main instructions 
call
for JDK 7 installation and then the footnote specifically tells 
developers
to pull a different JDK version for those earlier platforms.  I 
can't tell

where the Java 7 language features were added to Android before the
current
version, Lollipop.  I was surprised Lollipop wasn't on their 
dashboard but
according to the AppBrain statistics it accounts for far less than 
1% of
the installed phones.  So best case scenario would be Jelly Bean 
supports

7
(no indication that's true), which means 85% of Android devices 
would be
covered if we set a Java 7 minimum.  Next best would be KitKat 
(more

likely
but not according to the install instructions) which means 39%.  As 
for
Java 5, that was needed for pre-Gingerbread Android OS which 
accounts for

0.5% of the market.

I guess with all of that it's clear that Java 5 is unnecessarily 
being
maintained at this point.  Both surveys of servers and Android show 
far
less than 1% usage.  It seems Java 6 penetration may be still be 
pretty
substantial, even conservatively at on the order of 25% (if Java 7 
and 8
adoption picked up dramatically in 6 months after the surveys as I 
imagine
it did to some extent).  So it seems the most reasonable 
conservative play
would be to stick with Java 6, especially if we can confirm that 
between
half to 85% of Android devices can't use Java 7 language features.  
A more
aggressive play would be to set a requirement for Java 7.  Setting 
the

minimum at Java 8 at this time seems overly aggressive at this time
though.

https://plumbr.eu/blog/most-popular-java-environments-in-2014

http://pages.zeroturnaround.com/Java-Tools-Technologies.html

http://source.android.com/source/initializing.html

https://developer.android.com/about/dashboards/index.html

http://www.appbrain.com/stats/top-android-sdk-versions



I wonder: Isn't the "end of public updates"[1] (scheduled on April 
of

this year for Java 7) somehow going to change that picture a lot?
If not, why?


Regards,
Gilles

[1] http://www.oracle.com/technetwork/java/eol-135779.html





On Wed, Jan 14, 2015 at 11:20 PM, Silviu Burcea <
silviuburcea...@gmail.com>
wrote:

 I think Rebel Labs or Plumbr have some metrics about JDK usage.


On Wed, Jan 14, 2015 at 10:21 PM, Hank Grabowski <
h...@applieddefense.com>
wrote:

> Java 8 has only been out for less than a year.  There is still a
sizable
> percentage of groups that have not converted up to Java 8 for 
myriad

> reasons.  While I was surprised that we are requiring backwards
> compatibility with the ten year old Java 5 I think jumping all 
the way

to
> requiring Java 8 may be a bit too much of a stretch.  I would 
vote for

a
> minimum required version of Java 7 with the ability to run in 
Java 8.

I
> wish I could find metrics to quantify the penetration of each of 
the

JDKs,
> but my gut says Java 7 would a reasonable c

Re: [Math] Java version

[Gilles]

On Thu, 15 Jan 2015 17:42:43 +0100, Luc Maisonobe wrote:

Le 15/01/2015 17:15, Gilles a écrit :

On Thu, 15 Jan 2015 07:52:11 -0500, Hank Grabowski wrote:

Good call, Silviu!

The most recent version of their survey of Plumbr installations 
(823 in
total) was May of last year, only a few months after Java 8 came 
out

(link
below).  At that time the break down was: Java 5 at 0.4%, Java 6 at 
36%,
Java 7 at 61% and Java 8 at 2.5%.  I'm still looking for more data 
on

this,
but Rebel Labs has a similar article (not broken down by version) 
that
showed that 65% of development was on Java 7 by May of last year 
too. I
doubt the balance was Java 8 at that point, so there must be a 
sizable

Java
6 contingent still.

One other thing that came to mind with the new Java 8 features is 
how

that
is supported on Android.  As far as I can tell Android KitKat, as 
well as
the latest release of the Android Studio and SDK Tools doesn't 
support

Java
8 yet.  In fact, according to the Android development setup page 
versions
between (and including) Gingerbread and KitKat require JDK 6, not 
7.  I
haven't coded Android recently to know whether it does work on JDK 
7

or if
is just a requirement but it is peculiar that the main instructions 
call

for JDK 7 installation and then the footnote specifically tells
developers
to pull a different JDK version for those earlier platforms.  I 
can't

tell
where the Java 7 language features were added to Android before the
current
version, Lollipop.  I was surprised Lollipop wasn't on their 
dashboard

but
according to the AppBrain statistics it accounts for far less than 
1% of

the installed phones.  So best case scenario would be Jelly Bean
supports 7
(no indication that's true), which means 85% of Android devices 
would be
covered if we set a Java 7 minimum.  Next best would be KitKat 
(more

likely
but not according to the install instructions) which means 39%.  As 
for
Java 5, that was needed for pre-Gingerbread Android OS which 
accounts for

0.5% of the market.

I guess with all of that it's clear that Java 5 is unnecessarily 
being
maintained at this point.  Both surveys of servers and Android show 
far
less than 1% usage.  It seems Java 6 penetration may be still be 
pretty
substantial, even conservatively at on the order of 25% (if Java 7 
and 8

adoption picked up dramatically in 6 months after the surveys as I
imagine
it did to some extent).  So it seems the most reasonable 
conservative

play
would be to stick with Java 6, especially if we can confirm that 
between
half to 85% of Android devices can't use Java 7 language features.  
A

more
aggressive play would be to set a requirement for Java 7.  Setting 
the

minimum at Java 8 at this time seems overly aggressive at this time
though.

https://plumbr.eu/blog/most-popular-java-environments-in-2014

http://pages.zeroturnaround.com/Java-Tools-Technologies.html

http://source.android.com/source/initializing.html

https://developer.android.com/about/dashboards/index.html

http://www.appbrain.com/stats/top-android-sdk-versions


I wonder: Isn't the "end of public updates"[1] (scheduled on April 
of

this year for Java 7) somehow going to change that picture a lot?
If not, why?


I don't think so. If you take the use case Hank pointed out (Android
phones), many people want to be able to add new apps at will, but 
only a
smaller number will change the system completely and the JVM that 
comes
with it. And yes, there are Android applications that use Apache 
Commons

Math (and Orekit ;-).


I understand that the "mobile market" can be a concern, but I find
it dangerous that we use the upgrade limitations of that platform,
to constrain the development of a library that was not intended
for that platform in the first place.

Otherwise, the reasoning could be applied to Java itself: Why have
Java 8 when most phones won't upgrade?

Regards,
Gilles



best regards,
Luc




Regards,
Gilles

[1] http://www.oracle.com/technetwork/java/eol-135779.html




On Wed, Jan 14, 2015 at 11:20 PM, Silviu Burcea

wrote:


I think Rebel Labs or Plumbr have some metrics about JDK usage.

On Wed, Jan 14, 2015 at 10:21 PM, Hank Grabowski

wrote:

> Java 8 has only been out for less than a year.  There is still a
sizable
> percentage of groups that have not converted up to Java 8 for 
myriad

> reasons.  While I was surprised that we are requiring backwards
> compatibility with the ten year old Java 5 I think jumping all 
the

way to
> requiring Java 8 may be a bit too much of a stretch.  I would 
vote

for a
> minimum required version of Java 7 with the ability to run in 
Java

8.  I
> wish I could find metrics to quantify the penetration of each of 
the

JDKs,
> but my gut says Java 7 would a reasonable cutoff.
>
> On Tue, Jan 13, 2015 at 8:31 PM, Gilles 


> wrote:
>
> > Raising this issue once again.
> >>> Are we going to upgrade the requirement for the next major
release?
> >>>
> >>>  [ ] Java 5
> >>>  [ ] Java 6
> >>>  [ ] Java 7
> >>>  [ ] 

Re: [Math] Java version

[Hank Grabowski]

You would think so, but Java 6 hasn't been updated since early 2013 and is
still a quarter or more of the installed Java base.  The support for highly
scalable parallel operations that the new Java 8 language features get is
very tempting though.  Could we have a Java 8 branch on the core library
and release a CM for each of them until the vestigial versions are
sufficiently low enough on the usage chain?  I know there are some
versioning and release nightmares that could introduce but with the
parallel functions maybe it would be worth it unlike the changes that 6 to
7 would give for the project.

On Thu, Jan 15, 2015 at 11:15 AM, Gilles 
wrote:

> On Thu, 15 Jan 2015 07:52:11 -0500, Hank Grabowski wrote:
>
>> Good call, Silviu!
>>
>> The most recent version of their survey of Plumbr installations (823 in
>> total) was May of last year, only a few months after Java 8 came out (link
>> below).  At that time the break down was: Java 5 at 0.4%, Java 6 at 36%,
>> Java 7 at 61% and Java 8 at 2.5%.  I'm still looking for more data on
>> this,
>> but Rebel Labs has a similar article (not broken down by version) that
>> showed that 65% of development was on Java 7 by May of last year too. I
>> doubt the balance was Java 8 at that point, so there must be a sizable
>> Java
>> 6 contingent still.
>>
>> One other thing that came to mind with the new Java 8 features is how that
>> is supported on Android.  As far as I can tell Android KitKat, as well as
>> the latest release of the Android Studio and SDK Tools doesn't support
>> Java
>> 8 yet.  In fact, according to the Android development setup page versions
>> between (and including) Gingerbread and KitKat require JDK 6, not 7.  I
>> haven't coded Android recently to know whether it does work on JDK 7 or if
>> is just a requirement but it is peculiar that the main instructions call
>> for JDK 7 installation and then the footnote specifically tells developers
>> to pull a different JDK version for those earlier platforms.  I can't tell
>> where the Java 7 language features were added to Android before the
>> current
>> version, Lollipop.  I was surprised Lollipop wasn't on their dashboard but
>> according to the AppBrain statistics it accounts for far less than 1% of
>> the installed phones.  So best case scenario would be Jelly Bean supports
>> 7
>> (no indication that's true), which means 85% of Android devices would be
>> covered if we set a Java 7 minimum.  Next best would be KitKat (more
>> likely
>> but not according to the install instructions) which means 39%.  As for
>> Java 5, that was needed for pre-Gingerbread Android OS which accounts for
>> 0.5% of the market.
>>
>> I guess with all of that it's clear that Java 5 is unnecessarily being
>> maintained at this point.  Both surveys of servers and Android show far
>> less than 1% usage.  It seems Java 6 penetration may be still be pretty
>> substantial, even conservatively at on the order of 25% (if Java 7 and 8
>> adoption picked up dramatically in 6 months after the surveys as I imagine
>> it did to some extent).  So it seems the most reasonable conservative play
>> would be to stick with Java 6, especially if we can confirm that between
>> half to 85% of Android devices can't use Java 7 language features.  A more
>> aggressive play would be to set a requirement for Java 7.  Setting the
>> minimum at Java 8 at this time seems overly aggressive at this time
>> though.
>>
>> https://plumbr.eu/blog/most-popular-java-environments-in-2014
>>
>> http://pages.zeroturnaround.com/Java-Tools-Technologies.html
>>
>> http://source.android.com/source/initializing.html
>>
>> https://developer.android.com/about/dashboards/index.html
>>
>> http://www.appbrain.com/stats/top-android-sdk-versions
>>
>
> I wonder: Isn't the "end of public updates"[1] (scheduled on April of
> this year for Java 7) somehow going to change that picture a lot?
> If not, why?
>
>
> Regards,
> Gilles
>
> [1] http://www.oracle.com/technetwork/java/eol-135779.html
>
>
>
>
>> On Wed, Jan 14, 2015 at 11:20 PM, Silviu Burcea <
>> silviuburcea...@gmail.com>
>> wrote:
>>
>>  I think Rebel Labs or Plumbr have some metrics about JDK usage.
>>>
>>> On Wed, Jan 14, 2015 at 10:21 PM, Hank Grabowski <
>>> h...@applieddefense.com>
>>> wrote:
>>>
>>> > Java 8 has only been out for less than a year.  There is still a
>>> sizable
>>> > percentage of groups that have not converted up to Java 8 for myriad
>>> > reasons.  While I was surprised that we are requiring backwards
>>> > compatibility with the ten year old Java 5 I think jumping all the way
>>> to
>>> > requiring Java 8 may be a bit too much of a stretch.  I would vote for
>>> a
>>> > minimum required version of Java 7 with the ability to run in Java 8.
>>> I
>>> > wish I could find metrics to quantify the penetration of each of the
>>> JDKs,
>>> > but my gut says Java 7 would a reasonable cutoff.
>>> >
>>> > On Tue, Jan 13, 2015 at 8:31 PM, Gilles 
>>> > wrote:
>>> >
>>> > > Raising this issue once again.
>

Re: [Math] Java version

[Luc Maisonobe]

Le 15/01/2015 17:15, Gilles a écrit :
> On Thu, 15 Jan 2015 07:52:11 -0500, Hank Grabowski wrote:
>> Good call, Silviu!
>>
>> The most recent version of their survey of Plumbr installations (823 in
>> total) was May of last year, only a few months after Java 8 came out
>> (link
>> below).  At that time the break down was: Java 5 at 0.4%, Java 6 at 36%,
>> Java 7 at 61% and Java 8 at 2.5%.  I'm still looking for more data on
>> this,
>> but Rebel Labs has a similar article (not broken down by version) that
>> showed that 65% of development was on Java 7 by May of last year too. I
>> doubt the balance was Java 8 at that point, so there must be a sizable
>> Java
>> 6 contingent still.
>>
>> One other thing that came to mind with the new Java 8 features is how
>> that
>> is supported on Android.  As far as I can tell Android KitKat, as well as
>> the latest release of the Android Studio and SDK Tools doesn't support
>> Java
>> 8 yet.  In fact, according to the Android development setup page versions
>> between (and including) Gingerbread and KitKat require JDK 6, not 7.  I
>> haven't coded Android recently to know whether it does work on JDK 7
>> or if
>> is just a requirement but it is peculiar that the main instructions call
>> for JDK 7 installation and then the footnote specifically tells
>> developers
>> to pull a different JDK version for those earlier platforms.  I can't
>> tell
>> where the Java 7 language features were added to Android before the
>> current
>> version, Lollipop.  I was surprised Lollipop wasn't on their dashboard
>> but
>> according to the AppBrain statistics it accounts for far less than 1% of
>> the installed phones.  So best case scenario would be Jelly Bean
>> supports 7
>> (no indication that's true), which means 85% of Android devices would be
>> covered if we set a Java 7 minimum.  Next best would be KitKat (more
>> likely
>> but not according to the install instructions) which means 39%.  As for
>> Java 5, that was needed for pre-Gingerbread Android OS which accounts for
>> 0.5% of the market.
>>
>> I guess with all of that it's clear that Java 5 is unnecessarily being
>> maintained at this point.  Both surveys of servers and Android show far
>> less than 1% usage.  It seems Java 6 penetration may be still be pretty
>> substantial, even conservatively at on the order of 25% (if Java 7 and 8
>> adoption picked up dramatically in 6 months after the surveys as I
>> imagine
>> it did to some extent).  So it seems the most reasonable conservative
>> play
>> would be to stick with Java 6, especially if we can confirm that between
>> half to 85% of Android devices can't use Java 7 language features.  A
>> more
>> aggressive play would be to set a requirement for Java 7.  Setting the
>> minimum at Java 8 at this time seems overly aggressive at this time
>> though.
>>
>> https://plumbr.eu/blog/most-popular-java-environments-in-2014
>>
>> http://pages.zeroturnaround.com/Java-Tools-Technologies.html
>>
>> http://source.android.com/source/initializing.html
>>
>> https://developer.android.com/about/dashboards/index.html
>>
>> http://www.appbrain.com/stats/top-android-sdk-versions
> 
> I wonder: Isn't the "end of public updates"[1] (scheduled on April of
> this year for Java 7) somehow going to change that picture a lot?
> If not, why?

I don't think so. If you take the use case Hank pointed out (Android
phones), many people want to be able to add new apps at will, but only a
smaller number will change the system completely and the JVM that comes
with it. And yes, there are Android applications that use Apache Commons
Math (and Orekit ;-).

best regards,
Luc

> 
> 
> Regards,
> Gilles
> 
> [1] http://www.oracle.com/technetwork/java/eol-135779.html
> 
> 
>>
>> On Wed, Jan 14, 2015 at 11:20 PM, Silviu Burcea
>> 
>> wrote:
>>
>>> I think Rebel Labs or Plumbr have some metrics about JDK usage.
>>>
>>> On Wed, Jan 14, 2015 at 10:21 PM, Hank Grabowski
>>> 
>>> wrote:
>>>
>>> > Java 8 has only been out for less than a year.  There is still a
>>> sizable
>>> > percentage of groups that have not converted up to Java 8 for myriad
>>> > reasons.  While I was surprised that we are requiring backwards
>>> > compatibility with the ten year old Java 5 I think jumping all the
>>> way to
>>> > requiring Java 8 may be a bit too much of a stretch.  I would vote
>>> for a
>>> > minimum required version of Java 7 with the ability to run in Java
>>> 8.  I
>>> > wish I could find metrics to quantify the penetration of each of the
>>> JDKs,
>>> > but my gut says Java 7 would a reasonable cutoff.
>>> >
>>> > On Tue, Jan 13, 2015 at 8:31 PM, Gilles 
>>> > wrote:
>>> >
>>> > > Raising this issue once again.
>>> > >>> Are we going to upgrade the requirement for the next major
>>> release?
>>> > >>>
>>> > >>>  [ ] Java 5
>>> > >>>  [ ] Java 6
>>> > >>>  [ ] Java 7
>>> > >>>  [ ] Java 8
>>> > >>>  [ ] Java 9
>>> > >>>
>>> > >>
>>> > > Counts up to now:
>>> > >
>>> > > Java 7  -> 2
>>> > > Java 7 or 8 -> 2
>>> > > Ja

Re: [Math] Java version

[Gilles]

On Thu, 15 Jan 2015 07:52:11 -0500, Hank Grabowski wrote:

Good call, Silviu!

The most recent version of their survey of Plumbr installations (823 
in
total) was May of last year, only a few months after Java 8 came out 
(link
below).  At that time the break down was: Java 5 at 0.4%, Java 6 at 
36%,
Java 7 at 61% and Java 8 at 2.5%.  I'm still looking for more data on 
this,
but Rebel Labs has a similar article (not broken down by version) 
that
showed that 65% of development was on Java 7 by May of last year too. 
I
doubt the balance was Java 8 at that point, so there must be a 
sizable Java

6 contingent still.

One other thing that came to mind with the new Java 8 features is how 
that
is supported on Android.  As far as I can tell Android KitKat, as 
well as
the latest release of the Android Studio and SDK Tools doesn't 
support Java
8 yet.  In fact, according to the Android development setup page 
versions
between (and including) Gingerbread and KitKat require JDK 6, not 7.  
I
haven't coded Android recently to know whether it does work on JDK 7 
or if
is just a requirement but it is peculiar that the main instructions 
call
for JDK 7 installation and then the footnote specifically tells 
developers
to pull a different JDK version for those earlier platforms.  I can't 
tell
where the Java 7 language features were added to Android before the 
current
version, Lollipop.  I was surprised Lollipop wasn't on their 
dashboard but
according to the AppBrain statistics it accounts for far less than 1% 
of
the installed phones.  So best case scenario would be Jelly Bean 
supports 7
(no indication that's true), which means 85% of Android devices would 
be
covered if we set a Java 7 minimum.  Next best would be KitKat (more 
likely
but not according to the install instructions) which means 39%.  As 
for
Java 5, that was needed for pre-Gingerbread Android OS which accounts 
for

0.5% of the market.

I guess with all of that it's clear that Java 5 is unnecessarily 
being
maintained at this point.  Both surveys of servers and Android show 
far
less than 1% usage.  It seems Java 6 penetration may be still be 
pretty
substantial, even conservatively at on the order of 25% (if Java 7 
and 8
adoption picked up dramatically in 6 months after the surveys as I 
imagine
it did to some extent).  So it seems the most reasonable conservative 
play
would be to stick with Java 6, especially if we can confirm that 
between
half to 85% of Android devices can't use Java 7 language features.  A 
more
aggressive play would be to set a requirement for Java 7.  Setting 
the
minimum at Java 8 at this time seems overly aggressive at this time 
though.


https://plumbr.eu/blog/most-popular-java-environments-in-2014

http://pages.zeroturnaround.com/Java-Tools-Technologies.html

http://source.android.com/source/initializing.html

https://developer.android.com/about/dashboards/index.html

http://www.appbrain.com/stats/top-android-sdk-versions


I wonder: Isn't the "end of public updates"[1] (scheduled on April of
this year for Java 7) somehow going to change that picture a lot?
If not, why?


Regards,
Gilles

[1] http://www.oracle.com/technetwork/java/eol-135779.html




On Wed, Jan 14, 2015 at 11:20 PM, Silviu Burcea 


wrote:


I think Rebel Labs or Plumbr have some metrics about JDK usage.

On Wed, Jan 14, 2015 at 10:21 PM, Hank Grabowski 


wrote:

> Java 8 has only been out for less than a year.  There is still a 
sizable
> percentage of groups that have not converted up to Java 8 for 
myriad

> reasons.  While I was surprised that we are requiring backwards
> compatibility with the ten year old Java 5 I think jumping all the 
way to
> requiring Java 8 may be a bit too much of a stretch.  I would vote 
for a
> minimum required version of Java 7 with the ability to run in Java 
8.  I
> wish I could find metrics to quantify the penetration of each of 
the

JDKs,
> but my gut says Java 7 would a reasonable cutoff.
>
> On Tue, Jan 13, 2015 at 8:31 PM, Gilles 


> wrote:
>
> > Raising this issue once again.
> >>> Are we going to upgrade the requirement for the next major 
release?

> >>>
> >>>  [ ] Java 5
> >>>  [ ] Java 6
> >>>  [ ] Java 7
> >>>  [ ] Java 8
> >>>  [ ] Java 9
> >>>
> >>
> > Counts up to now:
> >
> > Java 7  -> 2
> > Java 7 or 8 -> 2
> > Java 8  -> 2
> >
> > Any more opionions?
> >
> > Gilles




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

Re: [Math] Java version

[Gilles]

On Thu, 15 Jan 2015 09:32:25 -0500, Hank Grabowski wrote:
If you are referring to default functions on interfaces, it's not 
going to
be like multiple inheritance C++ style.  Their rationale is to help 
for

backwards compatibility with upgraded interfaces that add methods.
Obviously it could be used to intentionally provide default methods 
from
the very beginning, but since I've never designed an interface with 
that
construct in mind I'm personally going to tread lightly with that 
idea.
Thankfully, as far as I know, if two interfaces have a default method 
with
the same signature then the code won't compile versus just "guessing" 
which

one you meant.

If the real crux is lambda expressions have we thought about doing
something with either Retrolambda (back porter) or  LambdaJ (Google's
Apache 2.0 licensed pre-Java 8 lambda library)?


For good or bad (another discussion), CM does not depend on any 
external
libraries, so as long as a feature is not part of the language, we 
cannot

experiment with it to code new features.

Once the features are in the language, it's a completely different 
matter,
IMHO: keeping them out of our development toolbox for too long may 
alienate

would-be contributors.
We cannot at the same time forbid usage of the newer features, and 
point

that nobody has come up with such usage.  It takes experimentation to
arrive at good usage; it's natural that people will not spend time 
doing

it if they know that the implementation will never make it to the
repository.


Best regards,
Gilles



On Thu, Jan 15, 2015 at 7:54 AM, Evan Ward  
wrote:


From an API perspective we can design a functional programming API 
in
Java 7, it will just be more verbose than in Java 8. One unique 
feature
that Java 8 does bring is multiple inheritance. Now that interfaces 
can
have method implementations classes can inherit methods from 
multiple
super classes. At this point I'm not sure how we would use this 
feature

as API designers, but it is another tool in the tool box.

I think 7 or 8 would be a good choice.

Regards,
Evan

On 01/14/2015 11:20 PM, Silviu Burcea wrote:
> I think Rebel Labs or Plumbr have some metrics about JDK usage.
>
> On Wed, Jan 14, 2015 at 10:21 PM, Hank Grabowski <
h...@applieddefense.com>
> wrote:
>
>> Java 8 has only been out for less than a year.  There is still a 
sizable
>> percentage of groups that have not converted up to Java 8 for 
myriad

>> reasons.  While I was surprised that we are requiring backwards
>> compatibility with the ten year old Java 5 I think jumping all 
the way

to
>> requiring Java 8 may be a bit too much of a stretch.  I would 
vote for a
>> minimum required version of Java 7 with the ability to run in 
Java 8.  I
>> wish I could find metrics to quantify the penetration of each of 
the

JDKs,
>> but my gut says Java 7 would a reasonable cutoff.
>>
>> On Tue, Jan 13, 2015 at 8:31 PM, Gilles 


>> wrote:
>>
>>> Raising this issue once again.
> Are we going to upgrade the requirement for the next major 
release?

>
>  [ ] Java 5
>  [ ] Java 6
>  [ ] Java 7
>  [ ] Java 8
>  [ ] Java 9
>
>>> Counts up to now:
>>>
>>> Java 7  -> 2
>>> Java 7 or 8 -> 2
>>> Java 8  -> 2
>>>
>>> Any more opionions?
>>>
>>> Gilles



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

Re: [Math] Java version

[Hank Grabowski]

Actually conflict resolution on multiple default methods is a little more
complicated (just fast forward to the 20 minute mark for the discussion on
that):

http://medianetwork.oracle.com/video/player/1113272518001


On Thu, Jan 15, 2015 at 9:32 AM, Hank Grabowski 
wrote:

> If you are referring to default functions on interfaces, it's not going to
> be like multiple inheritance C++ style.  Their rationale is to help for
> backwards compatibility with upgraded interfaces that add methods.
> Obviously it could be used to intentionally provide default methods from
> the very beginning, but since I've never designed an interface with that
> construct in mind I'm personally going to tread lightly with that idea.
> Thankfully, as far as I know, if two interfaces have a default method with
> the same signature then the code won't compile versus just "guessing" which
> one you meant.
>
> If the real crux is lambda expressions have we thought about doing
> something with either Retrolambda (back porter) or  LambdaJ (Google's
> Apache 2.0 licensed pre-Java 8 lambda library)?
>
> On Thu, Jan 15, 2015 at 7:54 AM, Evan Ward  wrote:
>
>> From an API perspective we can design a functional programming API in
>> Java 7, it will just be more verbose than in Java 8. One unique feature
>> that Java 8 does bring is multiple inheritance. Now that interfaces can
>> have method implementations classes can inherit methods from multiple
>> super classes. At this point I'm not sure how we would use this feature
>> as API designers, but it is another tool in the tool box.
>>
>> I think 7 or 8 would be a good choice.
>>
>> Regards,
>> Evan
>>
>> On 01/14/2015 11:20 PM, Silviu Burcea wrote:
>> > I think Rebel Labs or Plumbr have some metrics about JDK usage.
>> >
>> > On Wed, Jan 14, 2015 at 10:21 PM, Hank Grabowski <
>> h...@applieddefense.com>
>> > wrote:
>> >
>> >> Java 8 has only been out for less than a year.  There is still a
>> sizable
>> >> percentage of groups that have not converted up to Java 8 for myriad
>> >> reasons.  While I was surprised that we are requiring backwards
>> >> compatibility with the ten year old Java 5 I think jumping all the way
>> to
>> >> requiring Java 8 may be a bit too much of a stretch.  I would vote for
>> a
>> >> minimum required version of Java 7 with the ability to run in Java 8.
>> I
>> >> wish I could find metrics to quantify the penetration of each of the
>> JDKs,
>> >> but my gut says Java 7 would a reasonable cutoff.
>> >>
>> >> On Tue, Jan 13, 2015 at 8:31 PM, Gilles 
>> >> wrote:
>> >>
>> >>> Raising this issue once again.
>> > Are we going to upgrade the requirement for the next major release?
>> >
>> >  [ ] Java 5
>> >  [ ] Java 6
>> >  [ ] Java 7
>> >  [ ] Java 8
>> >  [ ] Java 9
>> >
>> >>> Counts up to now:
>> >>>
>> >>> Java 7  -> 2
>> >>> Java 7 or 8 -> 2
>> >>> Java 8  -> 2
>> >>>
>> >>> Any more opionions?
>> >>>
>> >>> Gilles
>> >>>
>> >>>
>> >>> -
>> >>> 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
>>
>>
>

Re: [Math] Java version

[Hank Grabowski]

If you are referring to default functions on interfaces, it's not going to
be like multiple inheritance C++ style.  Their rationale is to help for
backwards compatibility with upgraded interfaces that add methods.
Obviously it could be used to intentionally provide default methods from
the very beginning, but since I've never designed an interface with that
construct in mind I'm personally going to tread lightly with that idea.
Thankfully, as far as I know, if two interfaces have a default method with
the same signature then the code won't compile versus just "guessing" which
one you meant.

If the real crux is lambda expressions have we thought about doing
something with either Retrolambda (back porter) or  LambdaJ (Google's
Apache 2.0 licensed pre-Java 8 lambda library)?

On Thu, Jan 15, 2015 at 7:54 AM, Evan Ward  wrote:

> From an API perspective we can design a functional programming API in
> Java 7, it will just be more verbose than in Java 8. One unique feature
> that Java 8 does bring is multiple inheritance. Now that interfaces can
> have method implementations classes can inherit methods from multiple
> super classes. At this point I'm not sure how we would use this feature
> as API designers, but it is another tool in the tool box.
>
> I think 7 or 8 would be a good choice.
>
> Regards,
> Evan
>
> On 01/14/2015 11:20 PM, Silviu Burcea wrote:
> > I think Rebel Labs or Plumbr have some metrics about JDK usage.
> >
> > On Wed, Jan 14, 2015 at 10:21 PM, Hank Grabowski <
> h...@applieddefense.com>
> > wrote:
> >
> >> Java 8 has only been out for less than a year.  There is still a sizable
> >> percentage of groups that have not converted up to Java 8 for myriad
> >> reasons.  While I was surprised that we are requiring backwards
> >> compatibility with the ten year old Java 5 I think jumping all the way
> to
> >> requiring Java 8 may be a bit too much of a stretch.  I would vote for a
> >> minimum required version of Java 7 with the ability to run in Java 8.  I
> >> wish I could find metrics to quantify the penetration of each of the
> JDKs,
> >> but my gut says Java 7 would a reasonable cutoff.
> >>
> >> On Tue, Jan 13, 2015 at 8:31 PM, Gilles 
> >> wrote:
> >>
> >>> Raising this issue once again.
> > Are we going to upgrade the requirement for the next major release?
> >
> >  [ ] Java 5
> >  [ ] Java 6
> >  [ ] Java 7
> >  [ ] Java 8
> >  [ ] Java 9
> >
> >>> Counts up to now:
> >>>
> >>> Java 7  -> 2
> >>> Java 7 or 8 -> 2
> >>> Java 8  -> 2
> >>>
> >>> Any more opionions?
> >>>
> >>> Gilles
> >>>
> >>>
> >>> -
> >>> 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
>
>

Re: [Math] Java version

[Evan Ward]

From an API perspective we can design a functional programming API in
Java 7, it will just be more verbose than in Java 8. One unique feature
that Java 8 does bring is multiple inheritance. Now that interfaces can
have method implementations classes can inherit methods from multiple
super classes. At this point I'm not sure how we would use this feature
as API designers, but it is another tool in the tool box.

I think 7 or 8 would be a good choice.

Regards,
Evan

On 01/14/2015 11:20 PM, Silviu Burcea wrote:
> I think Rebel Labs or Plumbr have some metrics about JDK usage.
>
> On Wed, Jan 14, 2015 at 10:21 PM, Hank Grabowski 
> wrote:
>
>> Java 8 has only been out for less than a year.  There is still a sizable
>> percentage of groups that have not converted up to Java 8 for myriad
>> reasons.  While I was surprised that we are requiring backwards
>> compatibility with the ten year old Java 5 I think jumping all the way to
>> requiring Java 8 may be a bit too much of a stretch.  I would vote for a
>> minimum required version of Java 7 with the ability to run in Java 8.  I
>> wish I could find metrics to quantify the penetration of each of the JDKs,
>> but my gut says Java 7 would a reasonable cutoff.
>>
>> On Tue, Jan 13, 2015 at 8:31 PM, Gilles 
>> wrote:
>>
>>> Raising this issue once again.
> Are we going to upgrade the requirement for the next major release?
>
>  [ ] Java 5
>  [ ] Java 6
>  [ ] Java 7
>  [ ] Java 8
>  [ ] Java 9
>
>>> Counts up to now:
>>>
>>> Java 7  -> 2
>>> Java 7 or 8 -> 2
>>> Java 8  -> 2
>>>
>>> Any more opionions?
>>>
>>> Gilles
>>>
>>>
>>> -
>>> 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

Re: [Math] Java version

[Hank Grabowski]

Good call, Silviu!

The most recent version of their survey of Plumbr installations (823 in
total) was May of last year, only a few months after Java 8 came out (link
below).  At that time the break down was: Java 5 at 0.4%, Java 6 at 36%,
Java 7 at 61% and Java 8 at 2.5%.  I'm still looking for more data on this,
but Rebel Labs has a similar article (not broken down by version) that
showed that 65% of development was on Java 7 by May of last year too.  I
doubt the balance was Java 8 at that point, so there must be a sizable Java
6 contingent still.

One other thing that came to mind with the new Java 8 features is how that
is supported on Android.  As far as I can tell Android KitKat, as well as
the latest release of the Android Studio and SDK Tools doesn't support Java
8 yet.  In fact, according to the Android development setup page versions
between (and including) Gingerbread and KitKat require JDK 6, not 7.  I
haven't coded Android recently to know whether it does work on JDK 7 or if
is just a requirement but it is peculiar that the main instructions call
for JDK 7 installation and then the footnote specifically tells developers
to pull a different JDK version for those earlier platforms.  I can't tell
where the Java 7 language features were added to Android before the current
version, Lollipop.  I was surprised Lollipop wasn't on their dashboard but
according to the AppBrain statistics it accounts for far less than 1% of
the installed phones.  So best case scenario would be Jelly Bean supports 7
(no indication that's true), which means 85% of Android devices would be
covered if we set a Java 7 minimum.  Next best would be KitKat (more likely
but not according to the install instructions) which means 39%.  As for
Java 5, that was needed for pre-Gingerbread Android OS which accounts for
0.5% of the market.

I guess with all of that it's clear that Java 5 is unnecessarily being
maintained at this point.  Both surveys of servers and Android show far
less than 1% usage.  It seems Java 6 penetration may be still be pretty
substantial, even conservatively at on the order of 25% (if Java 7 and 8
adoption picked up dramatically in 6 months after the surveys as I imagine
it did to some extent).  So it seems the most reasonable conservative play
would be to stick with Java 6, especially if we can confirm that between
half to 85% of Android devices can't use Java 7 language features.  A more
aggressive play would be to set a requirement for Java 7.  Setting the
minimum at Java 8 at this time seems overly aggressive at this time though.

https://plumbr.eu/blog/most-popular-java-environments-in-2014

http://pages.zeroturnaround.com/Java-Tools-Technologies.html

http://source.android.com/source/initializing.html

https://developer.android.com/about/dashboards/index.html

http://www.appbrain.com/stats/top-android-sdk-versions


On Wed, Jan 14, 2015 at 11:20 PM, Silviu Burcea 
wrote:

> I think Rebel Labs or Plumbr have some metrics about JDK usage.
>
> On Wed, Jan 14, 2015 at 10:21 PM, Hank Grabowski 
> wrote:
>
> > Java 8 has only been out for less than a year.  There is still a sizable
> > percentage of groups that have not converted up to Java 8 for myriad
> > reasons.  While I was surprised that we are requiring backwards
> > compatibility with the ten year old Java 5 I think jumping all the way to
> > requiring Java 8 may be a bit too much of a stretch.  I would vote for a
> > minimum required version of Java 7 with the ability to run in Java 8.  I
> > wish I could find metrics to quantify the penetration of each of the
> JDKs,
> > but my gut says Java 7 would a reasonable cutoff.
> >
> > On Tue, Jan 13, 2015 at 8:31 PM, Gilles 
> > wrote:
> >
> > > Raising this issue once again.
> > >>> Are we going to upgrade the requirement for the next major release?
> > >>>
> > >>>  [ ] Java 5
> > >>>  [ ] Java 6
> > >>>  [ ] Java 7
> > >>>  [ ] Java 8
> > >>>  [ ] Java 9
> > >>>
> > >>
> > > Counts up to now:
> > >
> > > Java 7  -> 2
> > > Java 7 or 8 -> 2
> > > Java 8  -> 2
> > >
> > > Any more opionions?
> > >
> > > Gilles
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> > >
> >
>
>
>
> --
> - OCPJP7 (90%)
> - OCAJP7 (93%)
> - Java and Big Data Enthusiast
>

Re: [Math] Java version

[Silviu Burcea]

I think Rebel Labs or Plumbr have some metrics about JDK usage.

On Wed, Jan 14, 2015 at 10:21 PM, Hank Grabowski 
wrote:

> Java 8 has only been out for less than a year.  There is still a sizable
> percentage of groups that have not converted up to Java 8 for myriad
> reasons.  While I was surprised that we are requiring backwards
> compatibility with the ten year old Java 5 I think jumping all the way to
> requiring Java 8 may be a bit too much of a stretch.  I would vote for a
> minimum required version of Java 7 with the ability to run in Java 8.  I
> wish I could find metrics to quantify the penetration of each of the JDKs,
> but my gut says Java 7 would a reasonable cutoff.
>
> On Tue, Jan 13, 2015 at 8:31 PM, Gilles 
> wrote:
>
> > Raising this issue once again.
> >>> Are we going to upgrade the requirement for the next major release?
> >>>
> >>>  [ ] Java 5
> >>>  [ ] Java 6
> >>>  [ ] Java 7
> >>>  [ ] Java 8
> >>>  [ ] Java 9
> >>>
> >>
> > Counts up to now:
> >
> > Java 7  -> 2
> > Java 7 or 8 -> 2
> > Java 8  -> 2
> >
> > Any more opionions?
> >
> > Gilles
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>



-- 
- OCPJP7 (90%)
- OCAJP7 (93%)
- Java and Big Data Enthusiast

Re: [Math] Java version

[Hank Grabowski]

Java 8 has only been out for less than a year.  There is still a sizable
percentage of groups that have not converted up to Java 8 for myriad
reasons.  While I was surprised that we are requiring backwards
compatibility with the ten year old Java 5 I think jumping all the way to
requiring Java 8 may be a bit too much of a stretch.  I would vote for a
minimum required version of Java 7 with the ability to run in Java 8.  I
wish I could find metrics to quantify the penetration of each of the JDKs,
but my gut says Java 7 would a reasonable cutoff.

On Tue, Jan 13, 2015 at 8:31 PM, Gilles 
wrote:

> Raising this issue once again.
>>> Are we going to upgrade the requirement for the next major release?
>>>
>>>  [ ] Java 5
>>>  [ ] Java 6
>>>  [ ] Java 7
>>>  [ ] Java 8
>>>  [ ] Java 9
>>>
>>
> Counts up to now:
>
> Java 7  -> 2
> Java 7 or 8 -> 2
> Java 8  -> 2
>
> Any more opionions?
>
> Gilles
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [Math] Java version

[Ole Ersoy]

Converting an example from the user guide using Lambdas (Not an expert so bear 
with me - And note that the inputArray > inputStream):

BEFORE:

// Get a DescriptiveStatistics instance
DescriptiveStatistics stats = new DescriptiveStatistics();

// Add the data from the array
for( int i = 0; i < inputArray.length; i++) {
stats.addValue(inputArray[i]);
}

AFTER:
DescriptiveStatistics stats = new DescriptiveStatistics();
inputStream.forEach( value -> stats.addValue(value));

And now we can use Java 8's map, reduce, filter, sum, parallel, etc. on the 
inputStream.

Part of the reason for the rapid growth of NodeJS is that developers like 
functional programming.
Constructs like forEach, filter, map, and reduce are popular.  This paper has a 
lot of great examples
of things that can be done with these functions, and demonstrates adding simple 
concurrency with parallel().
http://ref.c24.biz/whitepapers/Java-8-for-Financial-Services.pdf

Cheers,
- Ole


On 01/14/2015 10:16 AM, Phil Steitz wrote:

On 1/14/15 4:38 AM, sebb wrote:

On 14 January 2015 at 08:18, Martin Grotle Soukup
 wrote:

Hi,

My two cents in favour of java 8:

IIUC the next major release will break backwards compatibility and aims to
clean up the API. Taking a look at the release frequency of commons math
[1], it shows releases every 9-12 months (give or take). Given that the
next big release is a major one (4.0), this indicate that a release in 2016
is a more likely target than in 2015.

It might be the case that people use java 6 or 7 today, but the picture
might be a different one a year from now.

Does Java 8 offer any benefits to the user?

No one has said much about this.  Could be some APIs could be
expressed better, but no one has provided any examples.

i.e. if CM is released for Java 7 or Java 6 would that impact on
people running Java 8?

No, unless they want to see language features used that are not used.

As a comparison, libraries that have not been updated to Java 5
generics do make a difference to Java 5+ users.
But enhanced for loops have no direct impact on the user.

There are really three things to think about when deciding whether
to require JDK x+

  1. Are there things you can't do / express without JDK x?
  2. Does requiring JDK x+ cut out a large portion of the user base?
  3. Are there a lot of things that are easier / simpler / more fun
 to implement in JDK x+?

Items 1. and 3. really impact developers and contributors; but being
too far out in 2. can indirectly influence that as well.  We went
for a long time requiring only 1.5 because there really was nothing
material for [math] in 1. and 3. included only a few things (most
commonly the compat bug I introduced in 3.4.1 due to missing array
copy, which is something we do a lot in [math]).

I think Martin's point on timing is a good one.  The last time I
looked at stats, the thundering herd was still 6-7.  Could be by the
time we actually cut 4.0, that will have changed.

It would be great though if someone could give some positive reasons
that JDK 8+ features really help us.  I am still in the 7 camp, due
to where the users are now; but if there are compelling 1. or 3.
things, I would be OK bumping to 8.

Phil


-
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

Re: [Math] Java version

[Phil Steitz]

On 1/14/15 4:38 AM, sebb wrote:
> On 14 January 2015 at 08:18, Martin Grotle Soukup
>  wrote:
>> Hi,
>>
>> My two cents in favour of java 8:
>>
>> IIUC the next major release will break backwards compatibility and aims to
>> clean up the API. Taking a look at the release frequency of commons math
>> [1], it shows releases every 9-12 months (give or take). Given that the
>> next big release is a major one (4.0), this indicate that a release in 2016
>> is a more likely target than in 2015.
>>
>> It might be the case that people use java 6 or 7 today, but the picture
>> might be a different one a year from now.
> Does Java 8 offer any benefits to the user?

No one has said much about this.  Could be some APIs could be
expressed better, but no one has provided any examples.
>
> i.e. if CM is released for Java 7 or Java 6 would that impact on
> people running Java 8?

No, unless they want to see language features used that are not used.
>
> As a comparison, libraries that have not been updated to Java 5
> generics do make a difference to Java 5+ users.
> But enhanced for loops have no direct impact on the user.

There are really three things to think about when deciding whether
to require JDK x+

 1. Are there things you can't do / express without JDK x?
 2. Does requiring JDK x+ cut out a large portion of the user base?
 3. Are there a lot of things that are easier / simpler / more fun
to implement in JDK x+?

Items 1. and 3. really impact developers and contributors; but being
too far out in 2. can indirectly influence that as well.  We went
for a long time requiring only 1.5 because there really was nothing
material for [math] in 1. and 3. included only a few things (most
commonly the compat bug I introduced in 3.4.1 due to missing array
copy, which is something we do a lot in [math]). 

I think Martin's point on timing is a good one.  The last time I
looked at stats, the thundering herd was still 6-7.  Could be by the
time we actually cut 4.0, that will have changed.

It would be great though if someone could give some positive reasons
that JDK 8+ features really help us.  I am still in the 7 camp, due
to where the users are now; but if there are compelling 1. or 3.
things, I would be OK bumping to 8.

Phil

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

Re: [Math] Java version

[sebb]

On 14 January 2015 at 08:18, Martin Grotle Soukup
 wrote:
> Hi,
>
> My two cents in favour of java 8:
>
> IIUC the next major release will break backwards compatibility and aims to
> clean up the API. Taking a look at the release frequency of commons math
> [1], it shows releases every 9-12 months (give or take). Given that the
> next big release is a major one (4.0), this indicate that a release in 2016
> is a more likely target than in 2015.
>
> It might be the case that people use java 6 or 7 today, but the picture
> might be a different one a year from now.

Does Java 8 offer any benefits to the user?

i.e. if CM is released for Java 7 or Java 6 would that impact on
people running Java 8?

As a comparison, libraries that have not been updated to Java 5
generics do make a difference to Java 5+ users.
But enhanced for loops have no direct impact on the user.

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

Re: [Math] Java version

[Martin Grotle Soukup]

Hi,

My two cents in favour of java 8:

IIUC the next major release will break backwards compatibility and aims to
clean up the API. Taking a look at the release frequency of commons math
[1], it shows releases every 9-12 months (give or take). Given that the
next big release is a major one (4.0), this indicate that a release in 2016
is a more likely target than in 2015.

It might be the case that people use java 6 or 7 today, but the picture
might be a different one a year from now.

I agree with Benedikt Ritter's comment earlier in this thread: "The
java.util.function package seems like a natural fit for a mathematics
library."

Vennlig hilsen
Martin Grotle Soukup
(+47) 95 90 34 02

[1] Latest releases of commons math:
2.2: 2011-03-02
3.0: 2012-03-12
3.1: 2012-12-24
3.2: 2013-04-07
3.3: 2014-05-16
3.4: 2014-12-28



2015-01-14 2:31 GMT+01:00 Gilles :

> Raising this issue once again.
>>> Are we going to upgrade the requirement for the next major release?
>>>
>>>  [ ] Java 5
>>>  [ ] Java 6
>>>  [ ] Java 7
>>>  [ ] Java 8
>>>  [ ] Java 9
>>>
>>
> Counts up to now:
>
> Java 7  -> 2
> Java 7 or 8 -> 2
> Java 8  -> 2
>
> Any more opionions?
>
> Gilles
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [Math] Java version

[Gary Gregory]

Java 7 or 8.

Gary

On Tue, Jan 13, 2015 at 8:31 PM, Gilles 
wrote:

> Raising this issue once again.
>>> Are we going to upgrade the requirement for the next major release?
>>>
>>>  [ ] Java 5
>>>  [ ] Java 6
>>>  [ ] Java 7
>>>  [ ] Java 8
>>>  [ ] Java 9
>>>
>>
> Counts up to now:
>
> Java 7  -> 2
> Java 7 or 8 -> 2
> Java 8  -> 2
>
> Any more opionions?
>
> Gilles
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [Math] Java version

[Ole Ersoy]

I would love to see Java 8.

Ole

On 01/13/2015 07:31 PM, Gilles wrote:

Raising this issue once again.
Are we going to upgrade the requirement for the next major release?

 [ ] Java 5
 [ ] Java 6
 [ ] Java 7
 [ ] Java 8
 [ ] Java 9


Counts up to now:

Java 7  -> 2
Java 7 or 8 -> 2
Java 8  -> 2

Any more opionions?

Gilles


-
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

Re: [Math] Java version

[Gilles]

Raising this issue once again.
Are we going to upgrade the requirement for the next major release?

 [ ] Java 5
 [ ] Java 6
 [ ] Java 7
 [ ] Java 8
 [ ] Java 9


Counts up to now:

Java 7  -> 2
Java 7 or 8 -> 2
Java 8  -> 2

Any more opionions?

Gilles


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

Re: [Math] Java version (Was: [MATH] Jenkins build)

[Luc Maisonobe]

Le 08/01/2015 12:34, Gilles a écrit :
> Hi.
> 
> Raising this issue once again.
> Are we going to upgrade the requirement for the next major release?
> 
>  [ ] Java 5
>  [ ] Java 6
>  [ ] Java 7
>  [ ] Java 8
>  [ ] Java 9

I would say 7 or 8.

best regards,
Luc

> 
> ?
> 
> Gilles
> 
> 
> On Thu, 8 Jan 2015 10:34:20 +, sebb wrote:
>> I've had to give up trying to get Continuum to use Git, so I set up a
>> Jenkins build for Math
>>
>> It seems Jenkins itself needs Java 1.6+, and the JAVA_1_x_HOME
>> variables don't seem to have been set up on the Jenkins hosts, so the
>> -Pjava-1.5 profile does not work as is.
>>
>> However I found that the JAVA_1_5_HOME variable can be defined on the
>> Maven command-line.
>>
>> This works, provided that Java 1.5 is always installed in the same
>> location on different hosts.
>>
>> [The JAVA_1_x_HOME variables were designed get around this
>> restriction, as they can be differently defined on different hosts]
>>
>> Hopefully the builds will be useful in detecting accidental use of
>> Java 1.6+ APIs
>>
>> So far I have only added Commons Math itself.
>> I hope to add the examples shortly.
>>
>> -
>> 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

Re: [Math] Java version (Was: [MATH] Jenkins build)

[James Carman]

I wouldn't think you'd want to begin anything "new" using an EOLed
version of Java.  I'd go with at least 7.

On Thu, Jan 8, 2015 at 6:34 AM, Gilles  wrote:
> Hi.
>
> Raising this issue once again.
> Are we going to upgrade the requirement for the next major release?
>
>  [ ] Java 5
>  [ ] Java 6
>  [ ] Java 7
>  [ ] Java 8
>  [ ] Java 9
>
> ?
>
> Gilles
>
>
> On Thu, 8 Jan 2015 10:34:20 +, sebb wrote:
>>
>> I've had to give up trying to get Continuum to use Git, so I set up a
>> Jenkins build for Math
>>
>> It seems Jenkins itself needs Java 1.6+, and the JAVA_1_x_HOME
>> variables don't seem to have been set up on the Jenkins hosts, so the
>> -Pjava-1.5 profile does not work as is.
>>
>> However I found that the JAVA_1_5_HOME variable can be defined on the
>> Maven command-line.
>>
>> This works, provided that Java 1.5 is always installed in the same
>> location on different hosts.
>>
>> [The JAVA_1_x_HOME variables were designed get around this
>> restriction, as they can be differently defined on different hosts]
>>
>> Hopefully the builds will be useful in detecting accidental use of
>> Java 1.6+ APIs
>>
>> So far I have only added Commons Math itself.
>> I hope to add the examples shortly.
>>
>> -
>> 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

Re: [Math] Java version (Was: [MATH] Jenkins build)

[Phil Steitz]

On 1/8/15 4:34 AM, Gilles wrote:
> Hi.
>
> Raising this issue once again.
> Are we going to upgrade the requirement for the next major release?
>
>  [ ] Java 5
>  [ ] Java 6
>  [x] Java 7
>  [ ] Java 8
>  [ ] Java 9

Phil
>
> ?
>
> Gilles
>
>
> On Thu, 8 Jan 2015 10:34:20 +, sebb wrote:
>> I've had to give up trying to get Continuum to use Git, so I set
>> up a
>> Jenkins build for Math
>>
>> It seems Jenkins itself needs Java 1.6+, and the JAVA_1_x_HOME
>> variables don't seem to have been set up on the Jenkins hosts, so
>> the
>> -Pjava-1.5 profile does not work as is.
>>
>> However I found that the JAVA_1_5_HOME variable can be defined on
>> the
>> Maven command-line.
>>
>> This works, provided that Java 1.5 is always installed in the same
>> location on different hosts.
>>
>> [The JAVA_1_x_HOME variables were designed get around this
>> restriction, as they can be differently defined on different hosts]
>>
>> Hopefully the builds will be useful in detecting accidental use of
>> Java 1.6+ APIs
>>
>> So far I have only added Commons Math itself.
>> I hope to add the examples shortly.
>>
>> -
>>
>> 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

Re: [Math] Java version (Was: [MATH] Jenkins build)

[Silviu Burcea]

My clients started to use Java 7 a few months before, so I wouldn't choose
Java 8. I know it's new and shinny and as a developer I'd love to play with
it, but unfortunately, users are using it. I'd go for Java 7 and plan Java
8 for Math 5.0

On Thu, Jan 8, 2015 at 4:16 PM, Benedikt Ritter  wrote:

> 2015-01-08 13:57 GMT+01:00 Martin Grotle Soukup <
> martin.grotle.sou...@gmail.com>:
>
> > Hi,
> >
> > I am only a user of the library, but I would be excited to see CM take
> > advantage of the new features of java 8.
> >
> > Best regards,
> > Martin Grotle Soukup
> >
> >
> > 2015-01-08 12:34 GMT+01:00 Gilles :
> >
> > > Hi.
> > >
> > > Raising this issue once again.
> > > Are we going to upgrade the requirement for the next major release?
> > >
> > >  [ ] Java 5
> > >  [ ] Java 6
> > >  [ ] Java 7
> > >  [x] Java 8
> >
>
> The java.util.function package seems like a natural fit for a mathematics
> library. OTOH my feeling is, that most users are still using Java 6/7...
>
> Benedikt
>
>
> > >  [ ] Java 9
> > >
> > > ?
> > >
> > > Gilles
> > >
> > >
> > > On Thu, 8 Jan 2015 10:34:20 +, sebb wrote:
> > >
> > >> I've had to give up trying to get Continuum to use Git, so I set up a
> > >> Jenkins build for Math
> > >>
> > >> It seems Jenkins itself needs Java 1.6+, and the JAVA_1_x_HOME
> > >> variables don't seem to have been set up on the Jenkins hosts, so the
> > >> -Pjava-1.5 profile does not work as is.
> > >>
> > >> However I found that the JAVA_1_5_HOME variable can be defined on the
> > >> Maven command-line.
> > >>
> > >> This works, provided that Java 1.5 is always installed in the same
> > >> location on different hosts.
> > >>
> > >> [The JAVA_1_x_HOME variables were designed get around this
> > >> restriction, as they can be differently defined on different hosts]
> > >>
> > >> Hopefully the builds will be useful in detecting accidental use of
> > >> Java 1.6+ APIs
> > >>
> > >> So far I have only added Commons Math itself.
> > >> I hope to add the examples shortly.
> > >>
> > >> -
> > >> 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
> > >
> > >
> >
>
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
>



-- 
- OCPJP7 (90%)
- OCAJP7 (93%)
- Java and Big Data Enthusiast

Re: [Math] Java version (Was: [MATH] Jenkins build)

[Benedikt Ritter]

2015-01-08 13:57 GMT+01:00 Martin Grotle Soukup <
martin.grotle.sou...@gmail.com>:

> Hi,
>
> I am only a user of the library, but I would be excited to see CM take
> advantage of the new features of java 8.
>
> Best regards,
> Martin Grotle Soukup
>
>
> 2015-01-08 12:34 GMT+01:00 Gilles :
>
> > Hi.
> >
> > Raising this issue once again.
> > Are we going to upgrade the requirement for the next major release?
> >
> >  [ ] Java 5
> >  [ ] Java 6
> >  [ ] Java 7
> >  [x] Java 8
>

The java.util.function package seems like a natural fit for a mathematics
library. OTOH my feeling is, that most users are still using Java 6/7...

Benedikt


> >  [ ] Java 9
> >
> > ?
> >
> > Gilles
> >
> >
> > On Thu, 8 Jan 2015 10:34:20 +, sebb wrote:
> >
> >> I've had to give up trying to get Continuum to use Git, so I set up a
> >> Jenkins build for Math
> >>
> >> It seems Jenkins itself needs Java 1.6+, and the JAVA_1_x_HOME
> >> variables don't seem to have been set up on the Jenkins hosts, so the
> >> -Pjava-1.5 profile does not work as is.
> >>
> >> However I found that the JAVA_1_5_HOME variable can be defined on the
> >> Maven command-line.
> >>
> >> This works, provided that Java 1.5 is always installed in the same
> >> location on different hosts.
> >>
> >> [The JAVA_1_x_HOME variables were designed get around this
> >> restriction, as they can be differently defined on different hosts]
> >>
> >> Hopefully the builds will be useful in detecting accidental use of
> >> Java 1.6+ APIs
> >>
> >> So far I have only added Commons Math itself.
> >> I hope to add the examples shortly.
> >>
> >> -
> >> 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
> >
> >
>



-- 
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter

Re: [Math] Java version (Was: [MATH] Jenkins build)

[Martin Grotle Soukup]

Hi,

I am only a user of the library, but I would be excited to see CM take
advantage of the new features of java 8.

Best regards,
Martin Grotle Soukup


2015-01-08 12:34 GMT+01:00 Gilles :

> Hi.
>
> Raising this issue once again.
> Are we going to upgrade the requirement for the next major release?
>
>  [ ] Java 5
>  [ ] Java 6
>  [ ] Java 7
>  [x] Java 8
>  [ ] Java 9
>
> ?
>
> Gilles
>
>
> On Thu, 8 Jan 2015 10:34:20 +, sebb wrote:
>
>> I've had to give up trying to get Continuum to use Git, so I set up a
>> Jenkins build for Math
>>
>> It seems Jenkins itself needs Java 1.6+, and the JAVA_1_x_HOME
>> variables don't seem to have been set up on the Jenkins hosts, so the
>> -Pjava-1.5 profile does not work as is.
>>
>> However I found that the JAVA_1_5_HOME variable can be defined on the
>> Maven command-line.
>>
>> This works, provided that Java 1.5 is always installed in the same
>> location on different hosts.
>>
>> [The JAVA_1_x_HOME variables were designed get around this
>> restriction, as they can be differently defined on different hosts]
>>
>> Hopefully the builds will be useful in detecting accidental use of
>> Java 1.6+ APIs
>>
>> So far I have only added Commons Math itself.
>> I hope to add the examples shortly.
>>
>> -
>> 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
>
>