The GeoTools discussion started getting into specific and I wanted a chance
to start the conversation here to focus on GeoServer challenges. The
proposal under discussion is here
https://github.com/geoserver/geoserver/wiki/GSIP-171
During the last meeting we provided some general feedback:
Proposal for GeoServer:
- GSIP 171 Java 18.9 Compatibility
- We can relax and just focus on running with Java 11
- Still using the CLASSPATH for geoserver
- Still use automatic module names
- As for repackaging just go ahead and untangle conflicts because we
are are not a library
This agrees with feedback I have gotten offline (a photo of a "SpringOne
Platform" presentation on this topic).
*Upgrade considerations*
*Consider staying on the JVM class-path*
- *Spring 5 runs fine in the class path mode as well as on the module
path*
- *however, other libraries may not work in a module setup quite yet*
- *Tomcat and co run in a custom class loader arrangement anyways*
*Consider staying at Java 8 byte code level*
- *Spring 5.1's ASM 7.0 fork accepts Java 8-12 bytecode level*
- *ASM 5.x (very common) rejects unknown bytecode levels beyond Java 8*
- *compiling your code with target 1.8 reduces risk of such tools
breaking*
*Build against Java 8, run against JDK 11?*
Specific concerns discussed in terms of:
- short term: run geoserver on the classpath
- mid term: run geoserver on classpath or module path, with some supporting
libraries on the classpath
- long term: run geoserver on the module path, with some supporting
libraries on the classpath
*Jars that are not ready?*
Jars that are not ready yet will have to stay on the CLASSPATH (jai,
jai-ext, imageio-ext, jai-tools). There is a small change to the GeoTools
factory interface (isAvailable, isAvailableStatus) to allow us to disable
functionality if a required jar is not found and report on the GeoServer
status page/rest api.
Short term we are on the classpath so we will not notice this issue.
Long term we expect geotools and geosever modules to remain automatic
modules so they can act as a bridge to the jars still on the classpath.
*Reflection and Unsafe*
Short term these will keep GeoServer on the CLASSPATH.
Medium term we will update components:
* Spring 4 --> Spring 5
* Hazelcast? Not ready yet
https://github.com/hazelcast/hazelcast/issues/13182
* XStream? Sort of ready (https://github.com/x-stream/xstream/issues/101)
and released as Stream 1.4.10 <http://x-stream.github.io/changes.html>. We
can open up our own classes to stream reflection as needed
* Hibernate? ready (https://www.thoughts-on-java.org/hibernate-5-3/) as of
Hibernate 5.3
Long term access to reflection and unsafe has been allowed - but access
needs to be granted.
--
Jody Garnett
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
