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:

Review of dependencies, update/replace with compatible versions as required:

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

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.

split package

The jar cannot be used on the module-path, should work on the classpath.

These are a Low priority to fix.

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

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:

--add-modules=jdk.unsupported

Examples:

  • ehcache-2.10.3

This may also be fixed by adding a module-info.java to geoserver enabling the java.desktop and jdk.unsupported.

java.desktop

As long as we enable "java.desktop" these jars will continue to function.

This can be fixed with either:

--add-modules=java.desktop

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 JPMS

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

Ideally we would like repackage the codebase, introducing MANIFEST.MF directives, producing a codebase that can run under both Java 8 and newer.

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.

Backwards Compatibility

User facing:

  • 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