-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Java 9 Compatibility
- Contact: Torben Barsballe
- TLDR: Make changes to GeoTools, with the ultimate goal of supporting the Java 11 / 18.9 LTS being released September 2018
- Branch(es):
- https://github.com/tbarsballe/geotools/tree/java9-compat-1.0
- Future branches TBD
Roadmap planning:
- Java 9 was released Sep 2017, and contains substantial changes to the inner workings of Java. EOL for Java 9 is Mar 2018.
- Java 10 releases in March 2018, EOL Sep 2018
- Java 11 is the next Java LTS, in Sep 2018.
GeoTools should be updated so that it is in a place where supporting Java 9, 18.3, and eventually 18.9 is viable. This will be a multi-step process, some of which has already been completed. This page tracks the how we are doing; linking to proposals as required for individual steps.
Risks:
-
One of the major changes introduced by java 9 was the jigsaw module system (for a primer on the module system, read The State of the Module System).
-
JSR-363 Unit of Measure system is being integrated into Java 10.3, conflicting with our old JSR-275 JScience implementation.
-
docklets api change [GEOT-6137|https://osgeo-org.atlassian.net/browse/GEOT-6137]
-
cross module javadoc
We may be able to avoid fixing this, as multiple jars will not be publishing into the same package?
-
Java 9 ServiceRegistry restrictions
A key regression for Java 9 was a change to ServiceRegistry which was used as GeoTools plugin system. This has been addressed by FactoryRegistry Refactoring for Java 9 Compatibility.
-
Java 9 GeoTools use of JAXB and Activation: We have documented the runtime parameters needed to activate this dormant JRE modules
-
SLDTransformTest differences in XML generation and CDATA:
Java 9 introduces some changes to XML pretty-printing. The new output is technically more accurate, but introduces a number of test failures in GeoTools.
https://github.com/geotools/geotools/pull/1790 https://github.com/geotools/geotools/pull/1798
-
CRS/Envelope precision issue:
Java 9 increased the precision of certain mathematical operations. This causes some tests that to exact comparisons of double values to fail due to rounding errors which are no longer present.
-
Required for compatibility with Java 18.3.
-
Java Jigsaw Module System dependency audit:
Each dependency does one of the following:
- Dependency includes module-info.java definition describing public packages
- MANIFEST.INF property defining the name to be used by automatic module system, "org.apache.commons.lang3"
- If nothing is provided the automatic module system will use the jar name, "apache-commons-lang-3.2.1"
It is our hope that to use "automatic module" for unmaintained dependencies that still work in Java 9.
-
Java Jigsaw Module System repackage: The first step to using jigsaw is to repackage our library so no two modules export the same package. This should involve refectory our jars, and will require a proposal for any API drift.
- Restructure GeoTools into Jigsaw modules
- [GEOT-6138|https://osgeo-org.atlassian.net/browse/GEOT-6138]
This breakdown of modules, will require shuffling into new jars. Work includes adding MANIFEST.INF property defining name to be used by automatic module system.
At this point GeoTools could be used with jigsaw, but still require command line parameters to activate JRE components.
-
Java Jigsaw Module System
- Add module-info.java definitions to our library and compile with Java 11
At this point GeoTools can be used with jigsaw out of the box, the module-info.java files activate JRE components preventing the need for workarounds in client applications.
Update: Java 9 introduced "multi-release jars" that can support more then one java version.
-
Java 11 GeoTools use of JAXB and Activation:
JAXB and Activation are Java EE modules, and as of Java 9 are not exported by default. They are required by GeoTools (mostly for imageio). All Java EE will eventually be dropped from Java and be managed by the Eclipse Foundation as the Jakarta project. When this occurs, we will need to include them as standalone dependencies.
-
imageio-ext use of JAXB
-
imageio repackage
More information needed.