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 <gil...@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
<gil...@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 <
silviuburcea...@gmail.com>
wrote:
I think Rebel Labs or Plumbr have some metrics about JDK usage.
On Wed, Jan 14, 2015 at 10:21 PM, Hank Grabowski <
h...@applieddefense.com>
wrote:
Java 8 has only been out for less than a year. There is still a
sizable
percentage of groups that have not converted up to Java 8 for
myriad
reasons. While I was surprised that we are requiring backwards
compatibility with the ten year old Java 5 I think jumping all
the way
to
requiring Java 8 may be a bit too much of a stretch. I would
vote for
a
minimum required version of Java 7 with the ability to run in
Java 8.
I
wish I could find metrics to quantify the penetration of each of
the
JDKs,
but my gut says Java 7 would a reasonable cutoff.
On Tue, Jan 13, 2015 at 8:31 PM, Gilles
<gil...@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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
