Is it time for Java8+ support?

[johnjaylward]

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:

1. Use of Java6 in some embedded devices that could not be upgraded
2. 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)

• https://jeroenmols.com/blog/2021/03/17/share-code-kotlin-multiplatform/

I think moving to at least Java 8 (preferably Java 11) would be beneficial in supporting the following options:

• Introduced with Java 7

  1. try-with-resources
  2. Multi-catch exceptions
  3. Type inference syntactic sugar
  4. Value literal syntactic sugar

• Introduced with Java 8 (LTS until 2022-03)

  1. Lambda support
  2. Optional support (feature requests Java8 Optional? #177, Support for Java 8 optionals #409)
  3. Method references
  4. New Date/Time classes (possibly adding new opt/get functions for them?)
  5. Improved type inference syntactic sugar
  6. New stream classes
  7. Performance improvements with HashMap key collisions

• Introduced in Java 9

  1. Modules (Feature requests Add Automatic-Module-Name to package #431, I would like to strictly name the module #451, No modules support #478, Make use of module-info.java #513) (Bug Not Working At All for java bean serialization. #480 - not working in modularized project)

• Introduced in Java 10

  1. Improved type inference syntactic sugar

• Introduced in Java 11 (LTS until 2023-09)

  1. Improves Lambda local variable support
  2. 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)

• Introduced with Java 12

  1. Switch Expressions and Pattern Matching
  2. Pattern Matching of instanceof
  3. Better GC performance for some use-cases

• Introduced with Java 13

  1. Text Blocks -> could be helpful for simplifying the look/feel of test data in test cases
  2. Improvements for Switch expressions from Java 12
  3. More GC improvements

• Introduced with Java 14

  1. Records -> We should ensure that our Bean->JSONObject code works for this new type
     1. There are new reflection points to make working with Records easy
  2. Better NPE messages, although we hopefully don't have anything that generates these

• Introduced with Java 15

  1. New "sealed" classes... not sure this is actually useful to us.
  2. New "hidden" classes, again not sure if this has any actual use for us

• Introduced with Java 16

  1. "Primitive Classes" -> Value based classes that act as primitives (i.e. Integer class would be treated as int primitive as far as the compiler/JVM are concerned). This would reduce boxing efforts when working with wrapper classes

• Introduced with Java 17 (LTS until 2026-09 or later, date subject to change)

  1. Nothing really new here not mentioned above to v12. Some of the items above are still labeled "incubator" or "preview" and are not fully supported in the LTS ("primitive classes" is one example)

[stleary]

Thanks, it's very helpful to lay out the factors affecting the choice of Java version support. I added the text as a Wiki page here: What Version of Java Should This Project Support?

Let me know if you have any issues or concerns with the Wiki page content.

I will leave this issue active for a week or so in case anyone wants to chime in.

[stleary]

Comments by @johnjaylward in #615

I don't believe the original author would have any qualms about updating the Java requirements. In 2014, he added support for java 1.8 (see commit a9a0762). It was later reverted (I believe after he did the hand-off to you). I don't believe he'd be against the update today if we ensured functionality.

Also, Some historical tickets referencing old support for java 8 (requesting lower version) as well as feature requests for java8+:

• Distribution is Java 1.8 #156
• latest jar 20150729 from Maven requires Java 8 #172
• multi-catch fixed for source release compatibility 1.6 #181
• Recompile at JDK 1.6 #197, Java 1.6 compatibility. #195
• stream.Collector initialized + some updates #201
• Improvement for JSONObject class #295

[stleary]

Please address how we can ensure that user projects won't break if they happen to be using Java 1.6, Android developers in particular. This is my main concern.

[johnjaylward]

1. Android developers targeting ancient versions of android should be able to use an older version of the library (baring any bug in a particular version)
2. Market share of different Android OS levels seem to indicate that around 12% of android phones are using an android version incompatable with Java 8+. Due to the "desugaring" tool that Android provides, anything targeting Java 8-11 will be "downgraded" to a compatible level that works with API24 or higher (Android 7 or higher)

Android 7 itself is already pretty old (as noted above this would be from 2016). Personally, I don't have any qualms about dropping support for anything that old.

Sadly, for Java itself, there probably isn't a reliable way to check market share of java install/tools, but my gut feeling, looking at IDE and Toolchain support over the last year, is that most developers WERE using 8 and are now using or switching to 11 or newer. Java 7 and 8 provided so many improvements to developers over Java 6, that I find it hard to believe that anyone has stuck with 6 this long on purpose.