Jody Garnett

This proposal is for GeoServer 2.15-M0 released in early 2019.

• Under Discussion
• In Progress
• Completed
• Rejected
• Deferred

Java 8 as a supported platform is reaching end-of-life January 2019, we have some work to do before GeoServer can run on recent versions of Java (mostly due to "jigsaw" module system).

Going forward the Java roadmap has changed to a six month release cycle, with both Oracle and OpenJDK participants offering various levels of "long-term-support" options.

This proposal covers the planning and time commitment to run under Java 18.9.

Required:

• Two supported platforms: Java 8, Java 11

Desirable:

• Single set of download artifacts usable on both Java 8 and Java 11.

Out of scope:

• Jakarta EE 8.0 is not expected to release until 2019 Q1, our work will continue to track JavaEE (and thus be limited to the classpath).

Java 11 places additional restrictions on reflection and new versions of many of our dependencies are available:

Activity covers review of dependencies, update/replace with compatible versions as required:

• Andrea has run the jdeps automatic tool detecting incompatible dependencies: Java 11 upgrade, looking for internal API usage.

• Jody has added a tab to the code spreadsheet for initial review task scheduling.

The jar cannot be used on the module-path due to conflict with another jar using the same package.

These are a Low priority to fix, these jars will remain on the classpath.

Examples:

• hatbox-1.0.b10.jar
• jta-1.1.jar
• stax-api-1.0.1.jar
• xml-apis-1.4.01.jar
• xml-apis-xerces-2.7.1.jar
• xom-1.1.jar
• ...

Technically you can also address these conflicts using patch-module startup option:

--patch-module java.xml=xom-1.1.jar --patch-module java.xml=xstream-1.4.10.jar

The jar cannot be used we need to update or replace.

These are a high priority to fix, and we may need to gracefully disable some functionality while we source a replacement (for example using a Factory.isAvailable() check to turn off a feature on Java 9).

Examples:

• dom4j-1.6.1.jar: This is a Java 1.4 era dependency, dom4j-2.1.1 is available ** https://dom4j.github.io ** org.relaxng.** will be repackaged in JDK 9. Users should include the org.relaxng.** types in the classpath.

As long as we enable "jdk.unsupported" these jars will continue to function. Warnings will show up in the logs but we will not be in a position to get rid of them until we can use their Java 11 safe replacements.

These are a low priority to fix, requiring the following startup option:

--add-modules jdk.unsupported --add-modules java.desktop --add-modules java.naming --add-modules java.xml --add-modules java.base --add-modules java.xml

jdk.unsupported examples:

• ehcache-2.10.3
• guava-25.1-jre.jar
• hazelcast-3.3.1.jar
• marlin-0.7.5-Unsafe.jar
• metrics-core-3.0.2.jar
• spring-core-4.3.18.RELEASE.jar
• ...

java.naming examples:

• spring-ldap-core-2.3.2.RELEASE.jar

java.desktop examples:

• marlin-0.7.5-Unsafe.jar

java.base examples:

• marlin-0.7.5-Unsafe.jar

java.xml examples:

• xom-1.1.jar

Older versions of spring are not compatible with Java 18.9. Upgrading to from Spring 4 to Spring 5 does involve handling some API changes, including:

• NativeJdbcExtractors in SpringUnWrapper no longer exist

Like Spring, HazelCast involves a lot of reflection. Any GeoServer components which use it will need to upgrade to a Java 18.9-compatible version.

• hazelcast-3.3.1 currently used
• jdeps just reports that ``--add-module jdk.unsupported` is required.

Any update available:

• hazelcast-3.10.3 latest stable
• 3.11-BETA-1 Release notes: Java 9 Compliance: Added support for modularization, Java 9 module system, while maintaining compatibility with Java 6.

Reference:

• Add Java 9+ support (modularization)

Changing to a Java 9 build chain, with target=1.8, is not required at this time.

Recommendation:

• Stick with a Java 8 build chain for this release cycle
• Revisit if we are blocked, or a future release when more developers use Java 11+

Notes:

• The maven-compiler-plugin provides recipe for having a Java 8 jar with a Java 9 module-info.

Despite the fact that this release of GeoServer will be JDK8 based we wish to start preparation for the module system:

• Repackage the codebase to resolve split-dependencies
• Introducing MANIFEST.MF directives, giving each module a stable name

Context:

• This work builds on the GeoTools Java-9-Compatibility efforts already underway, addressing incompatibilities with Factory SPI and units system.
• This work is done in conjunction with Restructure GeoTools into Jigsaw modules, a refactoring into jigsaw modules with some unavoidable package changes.

User facing:

• GeoServer will continue to function as a Java 8 application
• Our persistence mechanisms use full java classnames on occasion, and thus may be affected by any package changes.

Internal:

• Some repackaging of extensions and community modules to avoid conflict over package names may be required.

Project Steering Committee:

• Alessio Fabiani:
• Andrea Aime:
• Ben Caradoc-Davies:
• Brad Hards:
• Ian Turton:
• Jody Garnett: +1
• Jukka Rahkonen:
• Kevin Smith:
• Simone Giannecchini:

• Email Discussion:

  • Some look over at the world past Java 8 - Most recent discussion (Jul 2018)
  • GeoTools / GeoServer Meeting 2018-01-22 - Further details on testing GeoServer with Java 9 (Jan 2018)
  • GeoTools / GeoServer Meeting 2018-08-07
  • JDK 11 upgrade: split packages in GeoServer
  • GeoServer builds and runs on JDK11
  • Java 11 upgrade, looking for internal API

• EE4J Projects - Technical Direction - confirmation on the direction of Java Enterprise Edition

• Java Dependency Analysis Tool - good summary of what the errors mean and how to approach

• Five Command Line Options To Hack The Java Module System

• https://wiki.osgeo.org/wiki/Java_2018_Code_Sprint

  • To reduce travel costs we are looking at supporting multiple locations: North America and Europe.
  • We have some funding via OSGeo (thanks!) and will put together a sponsorship program to support this work.
  • Update: We have enough participants to run the sprint, many are working remotely to reduce costs. While this will impact productivity we will do our best to make effective use of everyones time.

• Pull Requests:

  • Initial support for JDK11: https://github.com/geoserver/geoserver/pull/3182

• Issue Tracker: GEOS-9082