You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Gilles <gi...@harfang.homelinux.org> on 2015/01/14 02:31:47 UTC
Re: [Math] Java version
>> 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 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
>
>