commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce A Johnson <johns...@umbc.edu>
Subject Re: [Math] Java version
Date Thu, 15 Jan 2015 19:34:46 GMT
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 <ole.ersoy@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 <gilles@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
>>> <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
>> 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


Mime
View raw message