Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
GSIP 171 - Java 18.9 Compatibility
Assigned to Release
This proposal is for GeoServer 2.15-M0 released in early 2019.
- Under Discussion
- In Progress
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.
- Two supported platforms: Java 8, Java 11
- 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).
Dependency Review / Update / Replace
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.
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
JDK removed internal API
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).
- 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
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.
Java 9 Build Chain (discussion)
Changing to a Java 9 build chain, with
target=1.8, is not required at this time.
- 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+
- The maven-compiler-plugin provides recipe for having a Java 8 jar with a Java 9 module-info.
Embrace Java Package Module System
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
MANIFEST.MFdirectives, giving each module a stable name
- 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.
- 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.
- 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:
- 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
- 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.
- Initial support for JDK11: https://github.com/geoserver/geoserver/pull/3182
Issue Tracker: GEOS-9082