Skip to content

Is it time for Java8+ support? #614

Closed
Closed
Is it time for Java8+ support?#614
Labels
Active discussion

Description

@johnjaylward
johnjaylward
opened on Jul 18, 2021

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

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

    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)

Activity

  1. stleary
    added
    Active discussion
    on Jul 19, 2021

  2. stleary commented on Jul 19, 2021

    @stleary
    stleary
    on Jul 19, 2021
    Owner

    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.

  3. stleary
    added
    Issue closed
    and removed
    Active discussion
    on Jul 19, 2021
  4. Repository owner locked and limited conversation to collaborators on Jul 19, 2021
  5. stleary
    closed this as completedon Jul 19, 2021
  6. Repository owner deleted a comment from GedMarc on Jul 19, 2021
  7. stleary
    added
    Active discussion
    and removed
    Issue closed
    on Jul 19, 2021
  8. stleary
    reopened this on Jul 19, 2021
  9. Repository owner unlocked this conversation on Jul 19, 2021

  10. stleary commented on Jul 19, 2021

    @stleary
    stleary
    on Jul 19, 2021
    Owner

    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+:

  11. stleary commented on Jul 19, 2021

    @stleary
    stleary
    on Jul 19, 2021
    Owner

    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.

  12. johnjaylward commented on Jul 19, 2021

    @johnjaylward
    johnjaylward
    on Jul 19, 2021
    ContributorAuthor
    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.

  13. johnjaylward commented on Jul 19, 2021

    @johnjaylward
    johnjaylward
    on Jul 19, 2021
    ContributorAuthor

    Here are the results of a developer survey published 1.5 years ago that show 3% of developers using Java7 or lower: https://snyk.io/blog/developers-dont-want-to-leave-java-8-as-64-hold-firm-on-their-preferred-release/

  14. stleary
    added
    Fix in progress
    and removed
    Fix in progress
    on Jul 24, 2021

  15. johnjaylward commented on Nov 24, 2021

    @johnjaylward
    johnjaylward
    on Nov 24, 2021
    ContributorAuthor

    Now that Java 17 is the new LTS version (java 11 still being in LTS support), Here are some highlights of features/improvements added to Java 12-17 that may be applicable to this project:

    • 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. Work has only been start on this via deprecation and other precursor changes. Actual value based classes are not in yet.
    • Introduced with Java 17 LTS
      1. Nothing really new here not mentioned above. Some of the items above are still labeled "incubator" or "preview" and are not fully supported in the LTS ("primitive classes" is one example)
  16. stleary
    added
    Hacktoberfest
    and removed
    Hacktoberfest
    on Sep 13, 2022

  17. Madjosz commented on Dec 13, 2022

    @Madjosz
    Madjosz
    on Dec 13, 2022
    Contributor

    @johnjaylward Which feature are you referring to with "Primitive Classes" for JDK 16? As far as I can see there is no such feature in https://openjdk.org/projects/jdk/16/ and Project Valhalla is still not visible on the horizon.

  18. johnjaylward commented on Dec 13, 2022

    @johnjaylward
    johnjaylward
    on Dec 13, 2022
    ContributorAuthor

    @johnjaylward Which feature are you referring to with "Primitive Classes" for JDK 16? As far as I can see there is no such feature in https://openjdk.org/projects/jdk/16/ and Project Valhalla is still not visible on the horizon.

    This is the article I pulled from I believe : https://www.infoworld.com/article/3569150/jdk-16-the-new-features-in-java-16.html

  19. Madjosz commented on Dec 14, 2022

    @Madjosz
    Madjosz
    on Dec 14, 2022
    Contributor

    The teaser exaggerates/shortens this a bit. The feature only adds new annotations to some classes, deprecates some already deprecated constructors 'for removal' and adds a new type of warning for synchronization, all in preparation for Valhalla. There are no actual value-based classes in this JEP https://openjdk.java.net/jeps/390

  20. johnjaylward commented on Sep 3, 2023

    @johnjaylward
    johnjaylward
    on Sep 3, 2023
    ContributorAuthor

    I believe this was resolved with #741 unless someone else has more to add to the discussion

  21. stleary commented on Sep 4, 2023

    @stleary
    stleary
    on Sep 4, 2023
    Owner

    Closing due to merge of #741

  22. stleary
    closed this as completedon Sep 4, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Active discussion

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions