Java 11 Compatibility

Date	2018 09 11	Contacts	María Arias de Reyna
Status	Research	Release	GeoNetwork 4.0
Resources	Initial research undertaken by GeoCat, expect additional activities to be required across the GeoNetwork community	Ticket #	OSGeo Java codesprint 2018
Source code	n/a
Funding	GeoCat providing initial assessment on behalf of GeoNetwork Enterprise product

Overview

The Java ecosystem is now lead by OpenJDK and has changed release cadence (two numbered release each year, with long-term-support releases every three years).

With this in mind there are two long-term-support releases:

Java 8 (LTS): 2014-2026 AdoptOpenJDK
Java 11 (LTS): 2018-2024 AdoptOpenJDK
Java 18 (LTS): 2021-TBA

Aside: We were initially concerned that Java 8 would no longer be supported, but an industry response lead by Red Hat, Eclipse Foundation and others is continuing to make OpenJDK 8 available to their customers and for Windows and macOS at http://adoptopenjdk.net.

Technical Details

2018 Initial Research

María Arias de Reyna participated in OSGeo Java 2018 Code Sprint:

OSGeo-Java-codesprint-2018

Results:

Naive Attempt: Run with maven/jetty
- As expected Spring fails to load
- Warnings on use of reflection "All illegal access operations will be denied in a future release"
Build with maven
- Missing javax classes (and probably even more missing/moved core JDK classes
- Warnings on use of reflection "All illegal access operations will be denied in a future release"

Requirements:

Replace Spring with latest version: from 3.2.0 to 5
Locate and replace all imports referencing missing JDK API
Replace other dependencies that may be struggling with JDK 11
Check all reflection

Assessment:

A new release of GeoTools is needed: Java 9 introduced a restriction on Service Registry (used by the GeoTools library to coordinate plugins) a new release of GeoTools will be required before GeoNetwork can run on Java 11
With some care releases of GeoNetwork should be compatible with both Java 8 and Java 11.

2020 Follow-up Research

Progress:

As part of https://github.com/geonetwork/core-geonetwork/wiki/Bolsena-2020:

Use of jdeps to short-list dependencies to replace (dreaded split-package problem)

Dependencies

For each dependency we need to look at how it is failing in Java 11, and if a new release is available to address the problem. As an example we know that an upgrade to Spring 5 is required for Java 11 compatibility.

Dependencies have some common failings:

Use of some internal com.sun classes or API.

This can occur when a dependency is using reflection to access a codec or other api directly for greater control, rather than making use of a more limited public api.

When running often only the first warning is reported, use --illegal-access=warn to report more.

Mitigation: Check if an official API is now available, this is often the case for reflection on the Unsafe class for improved memory management control. As an alternative look for an open source project that performs a similar function.
Unable to access a javax package that is expected to be included in the Java Runtime.

This can occur when a java runtime module is not turned on during startup (we can adjust this with JVM startup parameters for jetty or tomcat).

More seriously this can occur when the API is no longer part of Java, either because Java Enterprise Edition content has now moved to the Eclipse Foundation Jakarta project, or because functionality has been dropped from the Java ecosystem completely.
Split package error preventing the jar from being loaded

This occurs when a jar tries to publish a class into a package that is already used by another jar. As an example many of our xml libraries try to create additional classes in javax.xml package and fail to load as a result.

Mitigation: Ideally upgrade to a newer official version, or if we have to recompile our own fork (refactoring the code to use a unique package).