When: October 22-26th Where: North America (Victoria, BC), Europe (Italy or UK proposed), Oceania (recommendations welcome) Wiki: https://wiki.osgeo.org/wiki/Java_2018_Code_Sprint
If you or your project is interested in taking part, even remotely, please add yourself to the above wiki page! The Java community has a challenge ahead, with recent policy changes setting the Java platform on a six-month release cycle. We also have a *python3 moment* as our open source libraries are tasked with upgrading to the use of the "jigsaw" module system. Top level applications like GeoServer and GeoNetwork need to make some changes in order to run at all. Mostly this requires a dependency review, upgrading to new libraries such as Spring 5 that are compatible with Java 11. Many of these libraries are broken due to changes to how reflection is handled. Java libraries like JTS and GeoTools are put in an awkward position as a bottleneck on the safe use of the module system (see module hell problem <http://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html>). A further complication for is a restriction preventing two jars from making use of the same package. Planning is currently underway: - GSIP 171 Java 18.9 Compatibility <https://github.com/geoserver/geoserver/wiki/GSIP-171> (GeoServer) - Strategy for GeoNetwork <https://github.com/geonetwork/core-geonetwork/wiki/OSGeo-Java-codesprint-2018> - Restructure GeoTools into Jigsaw modules <https://github.com/geotools/geotools/wiki/Restructure-GeoTools-into-Jigsaw-modules> Recommended reading: - What Comes After JDK 8? <https://www.azul.com/what-comes-after-jdk-8/> - java release cycle changes - It's time! Migrating to Java 11 <https://medium.com/criciumadev/its-time-migrating-to-java-11-5eb3868354f9> - spring upgrade example - The State of the Module System <http://openjdk.java.net/projects/jigsaw/spec/sotms> - technical background
_______________________________________________ Discuss mailing list Discuss@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/discuss