With today's milestone release going out I am marking this proposal as complete ... -- Jody Garnett
On Wed, 26 Sep 2018 at 10:47, Jody Garnett <jody.garn...@gmail.com> wrote: > 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
