commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hank Grabowski <h...@applieddefense.com>
Subject Re: [Math] Java version
Date Thu, 15 Jan 2015 17:05:27 GMT
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 <gilles@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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message