Discussion

Java has a roadmap?

Yes, we had a previous sprint focused on Java 8 compatibility, several features had changed breaking compatibility.

More importantly the Java roadmap has changed to a six-month release cycle:

six month release cycle is already well underway having started with Java 9 and Java 10.

Oracle is offering three year LTS releases commercially

AdoptOpenJDK is setting up LTS releases of OpenJDK .. backed by IBM, Microsoft and others.

RedHat is focusing on LTS (skipping Java 9 and Java 10) and plans to ship OpenJDK based on Java SE 11

Why is updating our open source projects for the Java roadmap a challenge?

- Java changed the service provider interface plugin system used by GeoTools, forcing the project to write its own replacement.

- The java runtime has been broken up into modules, not all of which are activated by default. We need to review what sections of the JRE we require and ensure they are turned on.

- Java introduced the module system "jigsaw" providing both a class-path and module-path for loading jars.

- When loaded on the module-path jars are prevented from using the same package. This breaks multi-jar projects like GeoTools library where gt-api defining interfaces, and gt-main providing implementations.

- Jigsaw also locks down aspects of Java reflection, affecting projects like Spring that make heavy use of reflection to "auto wire" GeoServer together. Spring 5 has been released and upgrading to this release will be a key focus.

- With these changes projects like GeoServer need to review of hundreds open source dependencies to determine what other libraries are broken, if an update is available or replacement can be found.

- The java web service framework (responsible for concepts like Servlet and Session) is being removed from Oracle oversight and has been setup as [Jakarta EE Software](https://jakarta.ee).

In the above illustration the gt-svg module is used as an automatic module publishing org.geotools.renderer.style.svg package. It acts as a bridge to the multi-jar project batik still on the classpath, completely masking the fact batik is used used to read and render svg files. The core module gt-renderer publishes select packages for use, while hiding others. It makes use of ServiceLocator to access the IconFactory implemented by gt-svg and never has direct use of the batik implementation.

For this to work the gt-svg jar has been refactored, moving the icon factory the new package org.geotools.style.svg. This was required as the package org.geotools.renderer.style was already published by gt-renderer.

We expect:

Initial focus is on the core library, refactoring to allow jars to be used on the module path as named modules

plugins will remain on the classpath, accessed via service locator, any conflicting packages will not be visible to client code

Sprint Activities

The sprint is broken up into several stages, goal is to have something deliverable at the end of each stage. Care has been taken to identify activities that can be worked on in parallel.

Stage 1 Build and run in JDK 11

Everything in our stack builds and run without any flag added, off the classpath (it's ok to have warnings). This will allow us to get JDK 11 builds going.

*Compile:* Andrea has made considerable progress here, to mirror you need to check out and build locally all the dependencies

*Pass tests:* Passing tests can be worked on in parallel, as long as pervious stages were able to compile without tests. This work may require updating some dependencies

Project

Compile

Test

Build

jaitools

-

-

-

jai-ext

- x

-

-

imageio-ext

- x

-

-

geotools

- x

-

-

geowebcache

- x

-

-

geoserver

- x

-

-

How to sponsorship

Contributions will be put towards travel costs for sprint participants who would be otherwise unable to attend. Any surplus at the end of the event will be turned over to OSGeo or used for a future code sprint. We have set-up the sprint to minimize travel and accommodation costs.