You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by sebb <se...@gmail.com> on 2015/01/08 11:34:20 UTC
[MATH] Jenkins build
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Java version (Was: [MATH] Jenkins build)
Posted by James Carman <ja...@carmanconsulting.com>.
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 <gi...@harfang.homelinux.org> 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 +0000, 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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Java version
Posted by Phil Steitz <ph...@gmail.com>.
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
> 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
>> contributor base.
> I think these considerations are orthogonal:
>
> * what you want to do? aka scope of the projects
> * how you want to do it?
> * what infrastructure do you provide to your users/collaborators
>
>> 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!
> Afaik the scientific community uses mainly python with its abundance of
> great tools. I think Java is better suited in an engineering context.
>
> Thomas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Java version
Posted by Ole Ersoy <ol...@gmail.com>.
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
>>>> 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
>> contributor base.
> I think these considerations are orthogonal:
>
> * what you want to do? aka scope of the projects
> * how you want to do it?
> * what infrastructure do you provide to your users/collaborators
If someone needs a fast Thingy, and NodeJS has Thingy (And it's getting a lot of Thingys every day) then maybe commons math
just lost out on a few collaborators because what was preferred was:
- the community is growing / plenty of pulse
- functional programming structures
- shorter more concise code
- easier to scale
Cheers,
Ole
Re: [Math] Java version
Posted by Gilles <gi...@harfang.homelinux.org>.
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 long as it calculates the correct
> result, and is easy to use, imho.
I don't agree. Maybe it doesn't matter for the users (although it
should),
but it certainly does for the developers (maintainance, etc. etc.).
[If the "form" did not matter, why do several programming languages
exist?]
>> 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.
>
> I think these considerations are orthogonal:
It would be so easy if it were true, but there are interactions...
>
> * what you want to do? aka scope of the projects
> * how you want to do it?
> * what infrastructure do you provide to your users/collaborators
I try to point to that the stated goal of trying to gather more
contributors does not match the overly cautious policy with regard
to the language evolution.
>> 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!
>
> Afaik the scientific community uses mainly python with its abundance
> of
> great tools. I think Java is better suited in an engineering context.
That's a digression.
The point is to find the right balance (make users happy, make
developers
not too unhappy). But we must have facts to help determine a real
balance,
not just a balance between opinions (which is unlikely to happen).
For example, I'd propose that we advertize a poll with several precise
questions, to collect a statistics on various aspects that can
influence
a roadmap, like:
What package(s) of CM are you directly "import"ing in your
applications?
Which Java version are you using to develop applications that use CM?
Are you going to upgrade your applications with each new release of
CM?
What do you miss most in CM?
etc.
Short of doing it seriously, we might as well skip the divination
part. [That, IMHO, prevents CM from making progress (even through
mistakes, that's fine).]
Gilles
>
> Thomas
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Java version
Posted by Thomas Neidhart <th...@gmail.com>.
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
> contributor base.
I think these considerations are orthogonal:
* what you want to do? aka scope of the projects
* how you want to do it?
* what infrastructure do you provide to your users/collaborators
> 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!
Afaik the scientific community uses mainly python with its abundance of
great tools. I think Java is better suited in an engineering context.
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Java version
Posted by Gilles <gi...@harfang.homelinux.org>.
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Java version (Was: [MATH] Jenkins build)
Posted by James Carman <ja...@carmanconsulting.com>.
So, for places where you want to make use of streams, make your API
take a Stream<T> rather than a Collection<T> or whatever, and require
the user to choose whether to call parallelStream() or stream().
On Thu, Jan 15, 2015 at 5:41 PM, Phil Steitz <ph...@gmail.com> wrote:
> On 1/15/15 2:24 PM, Thomas Neidhart wrote:
>> On 01/08/2015 12:34 PM, Gilles wrote:
>>> Hi.
>>>
>>> Raising this issue once again.
>>> Are we going to upgrade the requirement for the next major release?
>>>
>> [ ] Java 5
>> [x] Java 6
>> [x] Java 7
>> [ ] Java 8
>> [ ] Java 9
>>
>> A while ago I thought that it would be cool to switch to Java 7/8 for
>> some of the nice new features (mainly fork/join, lambda expressions and
>> diamond operator, the rest is more or less unimportant for math imho).
>>
>> But after some thoughts I think they are not really needed for the
>> following reasons:
>>
>> * the main focus of math is on developing high-quality, well tested and
>> documented algorithms, the existing language features are more than
>> enough for this
>
> +1
>>
>> * coming up with multi-threaded algorithms might be appealing but it is
>> also hard work and I wonder if it really makes sense in the times of
>> projects like mahout / hadoop / ... which aim for even better scalability
>
> +1
>
> My HO is we should focus on getting the best single-threaded
> implementations we can and, where possible, setting things up to be
> executed in parallel by other engines. Spawning and managing
> threads internal to [math] actually *reduces* the range of
> applicability of our stuff. Much better to let Hadoop / Mahout et
> al parallelize using fast and accurate piece parts that we can
> provide. If there are parallel algorithms that we are really dying
> to implement directly, I would rather see that done in a way that
> encapsulates and enables externalization of the thread management.
>>
>> * staying at Java 6/7 does not block users to use math in a Java 8
>> environment if wanted
>
> +1 - the examples I have seen thus far are all things that could be
> done fairly easily with client code. I know we don't all agree with
> this, but I think the biggest service we can provide to our user
> base is good, tested, supported implementations of standard
> algorithms. I wish we could find a way to focus more on that and
> less on fiddling with the API or language features.
>
> Phil
>>
>> just my 2cents
>>
>> Thomas
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Java version (Was: [MATH] Jenkins build)
Posted by Phil Steitz <ph...@gmail.com>.
On 1/15/15 2:24 PM, Thomas Neidhart wrote:
> On 01/08/2015 12:34 PM, Gilles wrote:
>> Hi.
>>
>> Raising this issue once again.
>> Are we going to upgrade the requirement for the next major release?
>>
> [ ] Java 5
> [x] Java 6
> [x] Java 7
> [ ] Java 8
> [ ] Java 9
>
> A while ago I thought that it would be cool to switch to Java 7/8 for
> some of the nice new features (mainly fork/join, lambda expressions and
> diamond operator, the rest is more or less unimportant for math imho).
>
> But after some thoughts I think they are not really needed for the
> following reasons:
>
> * the main focus of math is on developing high-quality, well tested and
> documented algorithms, the existing language features are more than
> enough for this
+1
>
> * coming up with multi-threaded algorithms might be appealing but it is
> also hard work and I wonder if it really makes sense in the times of
> projects like mahout / hadoop / ... which aim for even better scalability
+1
My HO is we should focus on getting the best single-threaded
implementations we can and, where possible, setting things up to be
executed in parallel by other engines. Spawning and managing
threads internal to [math] actually *reduces* the range of
applicability of our stuff. Much better to let Hadoop / Mahout et
al parallelize using fast and accurate piece parts that we can
provide. If there are parallel algorithms that we are really dying
to implement directly, I would rather see that done in a way that
encapsulates and enables externalization of the thread management.
>
> * staying at Java 6/7 does not block users to use math in a Java 8
> environment if wanted
+1 - the examples I have seen thus far are all things that could be
done fairly easily with client code. I know we don't all agree with
this, but I think the biggest service we can provide to our user
base is good, tested, supported implementations of standard
algorithms. I wish we could find a way to focus more on that and
less on fiddling with the API or language features.
Phil
>
> just my 2cents
>
> Thomas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Java version (Was: [MATH] Jenkins build)
Posted by Ole Ersoy <ol...@gmail.com>.
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)
Posted by Thomas Neidhart <th...@gmail.com>.
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Java version (Was: [MATH] Jenkins build)
Posted by Silviu Burcea <si...@gmail.com>.
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 <br...@apache.org> wrote:
> 2015-01-08 13:57 GMT+01:00 Martin Grotle Soukup <
> martin.grotle.soukup@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 <gi...@harfang.homelinux.org>:
> >
> > > 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 +0000, 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-unsubscribe@commons.apache.org
> > >> For additional commands, e-mail: dev-help@commons.apache.org
> > >>
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
> >
>
>
>
> --
> 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)
Posted by Benedikt Ritter <br...@apache.org>.
2015-01-08 13:57 GMT+01:00 Martin Grotle Soukup <
martin.grotle.soukup@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 <gi...@harfang.homelinux.org>:
>
> > 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 +0000, 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-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
--
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)
Posted by Martin Grotle Soukup <ma...@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 <gi...@harfang.homelinux.org>:
> 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 +0000, 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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [Math] Java version (Was: [MATH] Jenkins build)
Posted by Phil Steitz <ph...@gmail.com>.
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 +0000, 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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
> .
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Java version
Posted by Gary Gregory <ga...@gmail.com>.
Java 7 or 8.
Gary
On Tue, Jan 13, 2015 at 8:31 PM, Gilles <gi...@harfang.homelinux.org>
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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [Math] Java version
Posted by Ole Ersoy <ol...@gmail.com>.
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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Java version
Posted by Ole Ersoy <ol...@gmail.com>.
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
>> <ma...@gmail.com> 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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Java version
Posted by Phil Steitz <ph...@gmail.com>.
On 1/14/15 4:38 AM, sebb wrote:
> On 14 January 2015 at 08:18, Martin Grotle Soukup
> <ma...@gmail.com> 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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Java version
Posted by sebb <se...@gmail.com>.
On 14 January 2015 at 08:18, Martin Grotle Soukup
<ma...@gmail.com> 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Java version
Posted by Martin Grotle Soukup <ma...@gmail.com>.
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 <gi...@harfang.homelinux.org>:
> 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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [Math] Java version
Posted by Hank Grabowski <ha...@applieddefense.com>.
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 <ha...@applieddefense.com>
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 <ev...@nrl.navy.mil> 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 <
>> hank@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 <gi...@harfang.homelinux.org>
>> >> 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-unsubscribe@commons.apache.org
>> >>> For additional commands, e-mail: dev-help@commons.apache.org
>> >>>
>> >>>
>> >
>> >
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
Re: [Math] Java version
Posted by Gilles <gi...@harfang.homelinux.org>.
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 <ev...@nrl.navy.mil>
> 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 <
>> hank@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
>> <gi...@harfang.homelinux.org>
>> >> 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Java version
Posted by Hank Grabowski <ha...@applieddefense.com>.
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 <ev...@nrl.navy.mil> 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 <
> hank@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 <gi...@harfang.homelinux.org>
> >> 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-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>
> >>>
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [Math] Java version
Posted by Evan Ward <ev...@nrl.navy.mil>.
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 <ha...@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 <gi...@harfang.homelinux.org>
>> 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-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Java version
Posted by Gilles <gi...@harfang.homelinux.org>.
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
>>> <si...@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
>>>> <ha...@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
>>>> <gi...@harfang.homelinux.org>
>>>> > 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Java version
Posted by Luc Maisonobe <lu...@spaceroots.org>.
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
>> <si...@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
>>> <ha...@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 <gi...@harfang.homelinux.org>
>>> > 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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Java version
Posted by Andy Seaborne <an...@apache.org>.
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 N<current is used
but 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
>> <si...@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
>>> <ha...@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 <gi...@harfang.homelinux.org>
>>> > 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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Java version
Posted by Emmanuel Bourg <eb...@apache.org>.
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Java version
Posted by Emmanuel Bourg <eb...@apache.org>.
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Java version
Posted by Ben McCann <be...@benmccann.com>.
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 <ol...@gmail.com> 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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
about.me/benmccann
Re: [Math] Java version
Posted by Ole Ersoy <ol...@gmail.com>.
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Java version
Posted by Gilles <gi...@harfang.homelinux.org>.
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Java version
Posted by Silviu Burcea <si...@gmail.com>.
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 <eb...@apache.org> 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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
- OCPJP7 (90%)
- OCAJP7 (93%)
- Java and Big Data Enthusiast
Re: [Math] Java version
Posted by Emmanuel Bourg <eb...@apache.org>.
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Java version
Posted by Gilles <gi...@harfang.homelinux.org>.
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Java version
Posted by Emmanuel Bourg <eb...@apache.org>.
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Java version
Posted by Bruce A Johnson <jo...@umbc.edu>.
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 <ol...@gmail.com> 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 <gi...@harfang.homelinux.org> 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
>>> <gi...@harfang.homelinux.org>
>>> 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 <
>>>>> silviuburceadev@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 <
>>>>>> hank@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
>>>>>> <gi...@harfang.homelinux.org>
>>>>>>> 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
>> My Vote for both Java 7 and 8
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Java version
Posted by Ole Ersoy <ol...@gmail.com>.
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 <gi...@harfang.homelinux.org> 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
>> <gi...@harfang.homelinux.org>
>> 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 <
>>>> silviuburceadev@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 <
>>>>> hank@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
>>>>> <gi...@harfang.homelinux.org>
>>>>>> 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
> My Vote for both Java 7 and 8
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Java version
Posted by venkatesha m <ts...@yahoo.com.INVALID>.
On Thursday, 15 January 2015 10:45 PM, Gilles <gi...@harfang.homelinux.org> 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
> <gi...@harfang.homelinux.org>
> 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 <
>>> silviuburceadev@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 <
>>>> hank@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
>>>> <gi...@harfang.homelinux.org>
>>>> > 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
My Vote for both Java 7 and 8
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Java version
Posted by Hank Grabowski <ha...@applieddefense.com>.
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 <gi...@harfang.homelinux.org>
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 <gi...@harfang.homelinux.org>
>> 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 <
>>>> silviuburceadev@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 <
>>>>> hank@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 <
>>>>> gilles@harfang.homelinux.org>
>>>>> > 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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [Math] Java version
Posted by Gilles <gi...@harfang.homelinux.org>.
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
> <gi...@harfang.homelinux.org>
> 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 <
>>> silviuburceadev@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 <
>>>> hank@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
>>>> <gi...@harfang.homelinux.org>
>>>> > 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Java version
Posted by Hank Grabowski <ha...@applieddefense.com>.
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 <gi...@harfang.homelinux.org>
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 <
>> silviuburceadev@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 <
>>> hank@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 <gi...@harfang.homelinux.org>
>>> > 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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [Math] Java version
Posted by Gilles <gi...@harfang.homelinux.org>.
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
> <si...@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
>> <ha...@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
>> <gi...@harfang.homelinux.org>
>> > 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Java version
Posted by Hank Grabowski <ha...@applieddefense.com>.
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 <si...@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 <ha...@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 <gi...@harfang.homelinux.org>
> > 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-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
> >
>
>
>
> --
> - OCPJP7 (90%)
> - OCAJP7 (93%)
> - Java and Big Data Enthusiast
>
Re: [Math] Java version
Posted by Silviu Burcea <si...@gmail.com>.
I think Rebel Labs or Plumbr have some metrics about JDK usage.
On Wed, Jan 14, 2015 at 10:21 PM, Hank Grabowski <ha...@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 <gi...@harfang.homelinux.org>
> 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-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
--
- OCPJP7 (90%)
- OCAJP7 (93%)
- Java and Big Data Enthusiast
Re: [Math] Java version
Posted by Hank Grabowski <ha...@applieddefense.com>.
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 <gi...@harfang.homelinux.org>
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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [Math] Java version
Posted by Gilles <gi...@harfang.homelinux.org>.
>> 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Java version (Was: [MATH] Jenkins build)
Posted by Luc Maisonobe <lu...@spaceroots.org>.
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 +0000, 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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
[Math] Java version (Was: [MATH] Jenkins build)
Posted by Gilles <gi...@harfang.homelinux.org>.
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 +0000, 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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org