-
Notifications
You must be signed in to change notification settings - Fork 2.6k
What Version of Java Should This Project Support?
Oracle itself has ended support for Java8 and many companies are starting to move off of 8 and onto at least 11 (the next [and current] LTS after 8). Oracle has the next LTS at 17 due Sept 2021.
Java 8 was released in 2014 and Java 11 in 2018. Java 6 was release first in 2006 and java 7 released in 2011. This puts us at requiring a fairly ancient version at this point. The last public release of Java6 was 2015 (6 years ago)
Some of the main reasons for us originally maintaining such an old version were:
- Use of Java6 in some embedded devices that could not be upgraded
- Requirement of Java6 APIs by Android.
I think at this time we can probably just drop the "embedded" limitation. Many of those devices are extremely old, and older versions of the library should be usable in those environments.
For Android, I did some digging, and it looks like Java 8 is still the "best" supported version, but Java 11 is supported through a "desugaring" tool that Android provides
- https://developer.android.com/studio/releases/platforms
- https://developer.android.com/studio/write/java8-support
- https://jakewharton.com/androids-java-8-support/ - indicates that Android API level 26 - Android 8 circa 2017 fully supports Java 8 bytecode through "desugaring". May be possible to target as far back as API 24 - circa 2016
- https://jakewharton.com/androids-java-9-10-11-and-12-support/ - indicates that moving to the latest LTS Java11 should be possible for us to do. (The outstanding issue for "desugaring" java 11 nested class changes now works - https://issuetracker.google.com/issues/130529338)
It appears that for now, bumping from Java 6 to 8 (or better 11) is a good move. Android also appears to be moving away from "java" as a language and instead to Kotlin. This may mean that if we switch to a higher language version (12+), Android may not support some newer APIs included in the new version (like the addition of java.time
in Java 8)
I think moving to at least Java 8 (preferably Java 11) would be beneficial in supporting the following options:
- Introduced with Java 7
try-with-resources
- Multi-catch exceptions
- Type inference syntactic sugar
- Value literal syntactic sugar
- Introduced with Java 8
- Lambda support
-
Optional
support (feature requests #177, #409) - Method references
- New Date/Time classes (possibly adding new
opt
/get
functions for them?) - Improved type inference syntactic sugar
- New
stream
classes - Performance improvements with
HashMap
key collisions
- Introduced in Java 9
- Modules (Feature requests #431, #451, #478, #513) (Bug #480 - not working in modularized project)
- Introduced in Java 10
- Improved type inference syntactic sugar
- Introduced in Java 11
- Improves Lambda local variable support
- Improved bytecode output for nested classes : No more $Outer$Inner.class generation and removal of synthetic accessors for nested elements (This should improve our performance of the
JSONObject.NULL
object)
johnjaylward - Issue #614