[OSGeo-Discuss] Java 11 code sprint taking shape for October 22-26th

[María Arias de Reyna]

Hi,

I have a tentative proposal from the local Java developer group here
in Sevilla to host and participate with volunteers on the codesprint
for GeoNetwork (which is where I can help most). Not sure how well
this will go, as most of them has no GIS experience, but I'm excited!

On Tue, Sep 18, 2018 at 9:58 AM Torsten Friebe <friebe at lat-lon.de> wrote:
>
> Hi Jody,
>
> thanks for setting up this code sprint. For the deegree project this
> is very important too. Besides getting deegree ready for Java 11+ we
> are also facing the issue that deegree code has dependencies to
> Oracle's JAI and other outdated libraries.
> I will share this with the deegree Developer mailing list and
> hopefully we can join the code sprint.
>
> Cheers
> Torsten
>
> Zitat von Jody Garnett <jody.garnett at gmail.com>:
>
> > 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
>
>
> --
> ### -->  Bitte beachten Sie unsere neuen Rufnummern!  <--  ###
>
> l a t / l o n  GmbH
> Aennchenstrasse 19                    53177 Bonn, Germany
> phone ++49 +228 9477 9877             fax ++49 +228 9477 0154
> http://www.lat-lon.de                 http://www.deegree.org
>
> lat/lon gesellschaft für raumbezogene informationssysteme mbH
> Registergericht: Amtsgericht Bonn, HRB 13042
> Geschäftsführer: Jens Fitzke und Torsten Friebe
>
> _______________________________________________
> Discuss mailing list
> Discuss at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/discuss