Skip to content

GSIP 171

Jump to bottom
Jody Garnett edited this page Oct 6, 2018 · 18 revisions

GSIP 171 - Java 18.9 Compatibility

Overview

Proposed By

Jody Garnett

Assigned to Release

This proposal is for GeoServer 2.15-RC scheduled for February 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:

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

Code Sprint 2018 Q4

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.

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, should work on the classpath.

These are a Low priority to fix:

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

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

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.

Java 9 Build Chain (out of scope)

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:
  • Jukka Rahkonen:
  • Kevin Smith:
  • Simone Giannecchini:

Links

©2020 Open Source Geospatial Foundation

Home
Proposals
Release Schedule

Clone this wiki locally