Skip to content

GSIP 171

Jump to bottom
Jody Garnett edited this page Dec 31, 2018 · 18 revisions

GSIP 171 - Java 18.9 Compatibility

Overview

Proposed By

Jody Garnett

Assigned to Release

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

State

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

Motivation

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.

Proposal

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).

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:

split package

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

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).

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.

jdk.unsupported, java.naming,

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

Spring 5

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

HazelCast

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:

Java 9 Build Chain (discussion)

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:

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
  • Introducing MANIFEST.MF directives, giving each module a stable name

Context:

Backwards Compatibility

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.

Feedback

Voting

Project Steering Committee:

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

Links

©2020 Open Source Geospatial Foundation

Home
Proposals
Release Schedule

Clone this wiki locally