[Geoserver-devel] Java 11 upgrade, looking for internal API usage

Andrea_Aime4 · September 30, 2018, 9:20am

Hi,
I am looking at internal API usage that we (likely) have to remove during the JDK 11 upgrade effort.

The jdeps tool can scan jars and find internal API usage, so I used it. I’ve already run it on jai-ext (no complaints),
imageio-ext (see results at https://github.com/geosolutions-it/imageio-ext/issues/172 ) and GeoTools (see mail
sent to geotools-devel).

Here are the results running it onto GeoServer (I’ve run assembly:attach, unpacked the WAR, then also unpacked all release
plugins into it, and run jdeps on the resulting WEB-INF/lib):

Warning: split package: java.sql jrt:/java.sql hatbox-1.0.b10.jar
Warning: split package: javax.transaction.xa jrt:/java.transaction.xa jta-1.1.jar
Warning: split package: javax.xml jrt:/java.xml stax-api-1.0.1.jar xml-apis-1.4.01.jar xml-apis-xerces-2.7.1.jar
Warning: split package: javax.xml.datatype jrt:/java.xml xml-apis-1.4.01.jar xml-apis-xerces-2.7.1.jar
Warning: split package: javax.xml.namespace jrt:/java.xml stax-api-1.0.1.jar xml-apis-1.4.01.jar xml-apis-xerces-2.7.1.jar xpp3-1.1.3.4.O.jar
Warning: split package: javax.xml.parsers jrt:/java.xml xml-apis-1.4.01.jar xml-apis-xerces-2.7.1.jar
Warning: split package: javax.xml.stream jrt:/java.xml stax-api-1.0.1.jar xml-apis-1.4.01.jar
Warning: split package: javax.xml.stream.events jrt:/java.xml stax-api-1.0.1.jar xml-apis-1.4.01.jar
Warning: split package: javax.xml.stream.util jrt:/java.xml stax-api-1.0.1.jar xml-apis-1.4.01.jar
Warning: split package: javax.xml.transform jrt:/java.xml xml-apis-1.4.01.jar xml-apis-xerces-2.7.1.jar
Warning: split package: javax.xml.transform.dom jrt:/java.xml xml-apis-1.4.01.jar xml-apis-xerces-2.7.1.jar
Warning: split package: javax.xml.transform.sax jrt:/java.xml xml-apis-1.4.01.jar xml-apis-xerces-2.7.1.jar
Warning: split package: javax.xml.transform.stax jrt:/java.xml xml-apis-1.4.01.jar
Warning: split package: javax.xml.transform.stream jrt:/java.xml xml-apis-1.4.01.jar xml-apis-xerces-2.7.1.jar
Warning: split package: javax.xml.validation jrt:/java.xml xml-apis-1.4.01.jar xml-apis-xerces-2.7.1.jar
Warning: split package: javax.xml.xpath jrt:/java.xml xml-apis-1.4.01.jar xml-apis-xerces-2.7.1.jar
Warning: split package: org.w3c.dom jrt:/java.xml xml-apis-1.4.01.jar xml-apis-xerces-2.7.1.jar xom-1.1.jar
Warning: split package: org.w3c.dom.bootstrap jrt:/java.xml xml-apis-1.4.01.jar xml-apis-xerces-2.7.1.jar
Warning: split package: org.w3c.dom.css jrt:/jdk.xml.dom xml-apis-1.4.01.jar xml-apis-xerces-2.7.1.jar
Warning: split package: org.w3c.dom.events jrt:/java.xml batik-ext-1.10.jar xml-apis-1.4.01.jar xml-apis-xerces-2.7.1.jar
Warning: split package: org.w3c.dom.html jrt:/jdk.xml.dom xercesImpl-2.11.0.jar xml-apis-1.4.01.jar xml-apis-xerces-2.7.1.jar
Warning: split package: org.w3c.dom.ls jrt:/java.xml xml-apis-1.4.01.jar xml-apis-xerces-2.7.1.jar
Warning: split package: org.w3c.dom.ranges jrt:/java.xml xml-apis-1.4.01.jar xml-apis-xerces-2.7.1.jar
Warning: split package: org.w3c.dom.stylesheets jrt:/jdk.xml.dom xml-apis-1.4.01.jar xml-apis-xerces-2.7.1.jar
Warning: split package: org.w3c.dom.traversal jrt:/java.xml xml-apis-1.4.01.jar xml-apis-xerces-2.7.1.jar
Warning: split package: org.w3c.dom.views jrt:/java.xml xml-apis-1.4.01.jar xml-apis-xerces-2.7.1.jar
Warning: split package: org.w3c.dom.xpath jrt:/jdk.xml.dom xml-apis-1.4.01.jar xml-apis-xerces-2.7.1.jar
Warning: split package: org.xml.sax jrt:/java.xml xml-apis-1.4.01.jar xml-apis-xerces-2.7.1.jar
Warning: split package: org.xml.sax.ext jrt:/java.xml xml-apis-1.4.01.jar xml-apis-xerces-2.7.1.jar
Warning: split package: org.xml.sax.helpers jrt:/java.xml xml-apis-1.4.01.jar xml-apis-xerces-2.7.1.jar
dom4j-1.6.1.jar → JDK removed internal API
org.dom4j.datatype.DatatypeAttribute → org.relaxng.datatype.DatatypeException JDK internal API (JDK removed internal API)
org.dom4j.datatype.DatatypeAttribute → org.relaxng.datatype.ValidationContext JDK internal API (JDK removed internal API)
org.dom4j.datatype.DatatypeElement → org.relaxng.datatype.DatatypeException JDK internal API (JDK removed internal API)
org.dom4j.datatype.DatatypeElement → org.relaxng.datatype.ValidationContext JDK internal API (JDK removed internal API)
org.dom4j.datatype.SchemaParser → org.relaxng.datatype.DatatypeException JDK internal API (JDK removed internal API)
org.dom4j.datatype.SchemaParser → org.relaxng.datatype.ValidationContext JDK internal API (JDK removed internal API)
ehcache-2.10.3.jar → jdk.unsupported
net.sf.ehcache.pool.sizeof.UnsafeSizeOf → sun.misc.Unsafe JDK internal API (jdk.unsupported)
freemarker-2.3.18.jar → java.xml
freemarker.ext.dom.SunInternalXalanXPathSupport → com.sun.org.apache.xml.internal.utils.PrefixResolver JDK internal API (java.xml)
freemarker.ext.dom.SunInternalXalanXPathSupport → com.sun.org.apache.xpath.internal.XPath JDK internal API (java.xml)
freemarker.ext.dom.SunInternalXalanXPathSupport → com.sun.org.apache.xpath.internal.XPathContext JDK internal API (java.xml)
freemarker.ext.dom.SunInternalXalanXPathSupport → com.sun.org.apache.xpath.internal.objects.XBoolean JDK internal API (java.xml)
freemarker.ext.dom.SunInternalXalanXPathSupport → com.sun.org.apache.xpath.internal.objects.XNodeSet JDK internal API (java.xml)
freemarker.ext.dom.SunInternalXalanXPathSupport → com.sun.org.apache.xpath.internal.objects.XNull JDK internal API (java.xml)
freemarker.ext.dom.SunInternalXalanXPathSupport → com.sun.org.apache.xpath.internal.objects.XNumber JDK internal API (java.xml)
freemarker.ext.dom.SunInternalXalanXPathSupport → com.sun.org.apache.xpath.internal.objects.XObject JDK internal API (java.xml)
freemarker.ext.dom.SunInternalXalanXPathSupport → com.sun.org.apache.xpath.internal.objects.XString JDK internal API (java.xml)
freemarker.ext.dom.SunInternalXalanXPathSupport$1 → com.sun.org.apache.xml.internal.utils.PrefixResolver JDK internal API (java.xml)
gs-platform-2.15-SNAPSHOT.jar → java.desktop
org.geoserver.platform.RenderingEngineStatus → sun.java2d.pipe.RenderingEngine JDK internal API (java.desktop)
gs-web-core-2.15-SNAPSHOT.jar → java.desktop
org.geoserver.web.admin.StatusPanel → sun.java2d.pipe.RenderingEngine JDK internal API (java.desktop)
gs-wms-2.15-SNAPSHOT.jar → java.xml
org.geoserver.wms.featureinfo.RasterLayerIdentifier → com.sun.org.apache.xml.internal.utils.XMLChar JDK internal API (java.xml)
gt-arcsde-21-SNAPSHOT.jar → java.desktop
org.geotools.arcsde.raster.info.RasterUtils → com.sun.imageio.plugins.common.BogusColorSpace JDK internal API (java.desktop)
gt-coverage-api-21-SNAPSHOT.jar → java.desktop
org.geotools.coverage.io.util.Utilities → sun.awt.OSInfo JDK internal API (java.desktop)
org.geotools.coverage.io.util.Utilities → sun.awt.OSInfo$OSType JDK internal API (java.desktop)
guava-25.1-jre.jar → jdk.unsupported
com.google.common.cache.Striped64 → sun.misc.Unsafe JDK internal API (jdk.unsupported)
com.google.common.cache.Striped64$1 → sun.misc.Unsafe JDK internal API (jdk.unsupported)
com.google.common.cache.Striped64$Cell → sun.misc.Unsafe JDK internal API (jdk.unsupported)
com.google.common.hash.LittleEndianByteArray$UnsafeByteArray → sun.misc.Unsafe JDK internal API (jdk.unsupported)
com.google.common.hash.LittleEndianByteArray$UnsafeByteArray$1 → sun.misc.Unsafe JDK internal API (jdk.unsupported)
com.google.common.hash.LittleEndianByteArray$UnsafeByteArray$2 → sun.misc.Unsafe JDK internal API (jdk.unsupported)
com.google.common.hash.LittleEndianByteArray$UnsafeByteArray$3 → sun.misc.Unsafe JDK internal API (jdk.unsupported)
com.google.common.hash.Striped64 → sun.misc.Unsafe JDK internal API (jdk.unsupported)
com.google.common.hash.Striped64$1 → sun.misc.Unsafe JDK internal API (jdk.unsupported)
com.google.common.hash.Striped64$Cell → sun.misc.Unsafe JDK internal API (jdk.unsupported)
com.google.common.primitives.UnsignedBytes$LexicographicalComparatorHolder$UnsafeComparator → sun.misc.Unsafe JDK internal API (jdk.unsupported)
com.google.common.primitives.UnsignedBytes$LexicographicalComparatorHolder$UnsafeComparator$1 → sun.misc.Unsafe JDK internal API (jdk.unsupported)
com.google.common.util.concurrent.AbstractFuture$UnsafeAtomicHelper → sun.misc.Unsafe JDK internal API (jdk.unsupported)
com.google.common.util.concurrent.AbstractFuture$UnsafeAtomicHelper$1 → sun.misc.Unsafe JDK internal API (jdk.unsupported)
gwc-wms-1.15-SNAPSHOT.jar → java.desktop
org.geowebcache.io.ImageEncoderImpl$WriteHelper$1 → com.sun.imageio.plugins.png.PNGImageWriter JDK internal API (java.desktop)
hazelcast-3.3.1.jar → jdk.unsupported
com.hazelcast.nio.UTFEncoderDecoder$UnsafeBasedCharArrayUtfWriter → sun.misc.Unsafe JDK internal API (jdk.unsupported)
com.hazelcast.nio.UnsafeHelper → sun.misc.Unsafe JDK internal API (jdk.unsupported)
com.hazelcast.nio.UnsafeHelper$1 → sun.misc.Unsafe JDK internal API (jdk.unsupported)
com.hazelcast.nio.serialization.UnsafeObjectDataInput → sun.misc.Unsafe JDK internal API (jdk.unsupported)
com.hazelcast.nio.serialization.UnsafeObjectDataOutput → sun.misc.Unsafe JDK internal API (jdk.unsupported)
imageio-ext-streams-1.1.25.jar → java.desktop
it.geosolutions.imageio.stream.input.spi.FileImageInputStreamExtImplSpi → com.sun.imageio.spi.FileImageInputStreamSpi JDK internal API (java.desktop)
it.geosolutions.imageio.stream.output.spi.FileImageOutputStreamExtImplSpi → com.sun.imageio.spi.FileImageOutputStreamSpi JDK internal API (java.desktop)
imageio-ext-utilities-1.1.25.jar → java.desktop
it.geosolutions.imageio.utilities.ImageIOUtilities → com.sun.imageio.plugins.common.BogusColorSpace JDK internal API (java.desktop)
jai_codec-1.1.3.jar → JDK removed internal API
jai_codec-1.1.3.jar → java.base
com.sun.media.jai.codecimpl.JPEGImage → com.sun.image.codec.jpeg.ImageFormatException JDK internal API (JDK removed internal API)
com.sun.media.jai.codecimpl.JPEGImage → com.sun.image.codec.jpeg.JPEGCodec JDK internal API (JDK removed internal API)
com.sun.media.jai.codecimpl.JPEGImage → com.sun.image.codec.jpeg.JPEGImageDecoder JDK internal API (JDK removed internal API)
com.sun.media.jai.codecimpl.JPEGImageEncoder → com.sun.image.codec.jpeg.JPEGCodec JDK internal API (JDK removed internal API)
com.sun.media.jai.codecimpl.JPEGImageEncoder → com.sun.image.codec.jpeg.JPEGEncodeParam JDK internal API (JDK removed internal API)
com.sun.media.jai.codecimpl.JPEGImageEncoder → com.sun.image.codec.jpeg.JPEGImageEncoder JDK internal API (JDK removed internal API)
com.sun.media.jai.codecimpl.JPEGImageEncoder → com.sun.image.codec.jpeg.JPEGQTable JDK internal API (JDK removed internal API)
com.sun.media.jai.codecimpl.PNMImage → sun.security.action.GetPropertyAction JDK internal API (java.base)
com.sun.media.jai.codecimpl.PNMImageEncoder → sun.security.action.GetPropertyAction JDK internal API (java.base)
com.sun.media.jai.codecimpl.TIFFImage → com.sun.image.codec.jpeg.JPEGCodec JDK internal API (JDK removed internal API)
com.sun.media.jai.codecimpl.TIFFImage → com.sun.image.codec.jpeg.JPEGDecodeParam JDK internal API (JDK removed internal API)
com.sun.media.jai.codecimpl.TIFFImage → com.sun.image.codec.jpeg.JPEGImageDecoder JDK internal API (JDK removed internal API)
com.sun.media.jai.codecimpl.TIFFImageEncoder → com.sun.image.codec.jpeg.JPEGCodec JDK internal API (JDK removed internal API)
com.sun.media.jai.codecimpl.TIFFImageEncoder → com.sun.image.codec.jpeg.JPEGEncodeParam JDK internal API (JDK removed internal API)
com.sun.media.jai.codecimpl.TIFFImageEncoder → com.sun.image.codec.jpeg.JPEGImageEncoder JDK internal API (JDK removed internal API)
com.sun.media.jai.codecimpl.fpx.FPXImage → com.sun.image.codec.jpeg.JPEGCodec JDK internal API (JDK removed internal API)
com.sun.media.jai.codecimpl.fpx.FPXImage → com.sun.image.codec.jpeg.JPEGDecodeParam JDK internal API (JDK removed internal API)
com.sun.media.jai.codecimpl.fpx.FPXImage → com.sun.image.codec.jpeg.JPEGImageDecoder JDK internal API (JDK removed internal API)
jai_core-1.1.3.jar → JDK removed internal API
jai_core-1.1.3.jar → java.desktop
com.sun.media.jai.opimage.IIPResolutionOpImage → com.sun.image.codec.jpeg.JPEGCodec JDK internal API (JDK removed internal API)
com.sun.media.jai.opimage.IIPResolutionOpImage → com.sun.image.codec.jpeg.JPEGDecodeParam JDK internal API (JDK removed internal API)
com.sun.media.jai.opimage.IIPResolutionOpImage → com.sun.image.codec.jpeg.JPEGImageDecoder JDK internal API (JDK removed internal API)
com.sun.media.jai.tilecodec.JPEGTileDecoder → com.sun.image.codec.jpeg.JPEGCodec JDK internal API (JDK removed internal API)
com.sun.media.jai.tilecodec.JPEGTileDecoder → com.sun.image.codec.jpeg.JPEGDecodeParam JDK internal API (JDK removed internal API)
com.sun.media.jai.tilecodec.JPEGTileDecoder → com.sun.image.codec.jpeg.JPEGImageDecoder JDK internal API (JDK removed internal API)
com.sun.media.jai.tilecodec.JPEGTileDecoder → com.sun.image.codec.jpeg.JPEGQTable JDK internal API (JDK removed internal API)
com.sun.media.jai.tilecodec.JPEGTileEncoder → com.sun.image.codec.jpeg.JPEGCodec JDK internal API (JDK removed internal API)
com.sun.media.jai.tilecodec.JPEGTileEncoder → com.sun.image.codec.jpeg.JPEGEncodeParam JDK internal API (JDK removed internal API)
com.sun.media.jai.tilecodec.JPEGTileEncoder → com.sun.image.codec.jpeg.JPEGImageEncoder JDK internal API (JDK removed internal API)
com.sun.media.jai.tilecodec.JPEGTileEncoder → com.sun.image.codec.jpeg.JPEGQTable JDK internal API (JDK removed internal API)
com.sun.media.jai.tilecodec.JPEGTileEncoder → sun.awt.image.codec.JPEGParam JDK internal API (JDK removed internal API)
javax.media.jai.RasterAccessor → sun.awt.image.BytePackedRaster JDK internal API (java.desktop)
jai_imageio-1.1.jar → java.base
com.sun.media.imageioimpl.plugins.pnm.PNMImageReader → sun.security.action.GetPropertyAction JDK internal API (java.base)
com.sun.media.imageioimpl.plugins.pnm.PNMImageWriter → sun.security.action.GetPropertyAction JDK internal API (java.base)
marlin-0.7.5-Unsafe.jar → java.base
marlin-0.7.5-Unsafe.jar → java.desktop
marlin-0.7.5-Unsafe.jar → jdk.unsupported
org.marlin.geom.Path2D → sun.awt.geom.Curve JDK internal API (java.desktop)
org.marlin.geom.Path2D$Double → sun.awt.geom.Curve JDK internal API (java.desktop)
org.marlin.geom.Path2D$Float → sun.awt.geom.Curve JDK internal API (java.desktop)
org.marlin.pisces.CollinearSimplifier → sun.awt.geom.PathConsumer2D JDK internal API (java.desktop)
org.marlin.pisces.DMarlinRenderingEngine → sun.awt.geom.PathConsumer2D JDK internal API (java.desktop)
org.marlin.pisces.DMarlinRenderingEngine → sun.java2d.pipe.AATileGenerator JDK internal API (java.desktop)
org.marlin.pisces.DMarlinRenderingEngine → sun.java2d.pipe.Region JDK internal API (java.desktop)
org.marlin.pisces.DMarlinRenderingEngine → sun.java2d.pipe.RenderingEngine JDK internal API (java.desktop)
org.marlin.pisces.DMarlinRenderingEngine → sun.security.action.GetPropertyAction JDK internal API (java.base)
org.marlin.pisces.DRenderer → sun.misc.Unsafe JDK internal API (jdk.unsupported)
org.marlin.pisces.DRendererContext$PathConsumer2DAdapter → sun.awt.geom.PathConsumer2D JDK internal API (java.desktop)
org.marlin.pisces.Dasher → sun.awt.geom.PathConsumer2D JDK internal API (java.desktop)
org.marlin.pisces.MarlinCache → sun.misc.Unsafe JDK internal API (jdk.unsupported)
org.marlin.pisces.MarlinProperties → sun.security.action.GetPropertyAction JDK internal API (java.base)
org.marlin.pisces.MarlinRenderingEngine → sun.awt.geom.PathConsumer2D JDK internal API (java.desktop)
org.marlin.pisces.MarlinRenderingEngine → sun.java2d.pipe.AATileGenerator JDK internal API (java.desktop)
org.marlin.pisces.MarlinRenderingEngine → sun.java2d.pipe.Region JDK internal API (java.desktop)
org.marlin.pisces.MarlinRenderingEngine → sun.java2d.pipe.RenderingEngine JDK internal API (java.desktop)
org.marlin.pisces.MarlinRenderingEngine → sun.security.action.GetPropertyAction JDK internal API (java.base)
org.marlin.pisces.MarlinTileGenerator → sun.java2d.pipe.AATileGenerator JDK internal API (java.desktop)
org.marlin.pisces.MarlinTileGenerator → sun.misc.Unsafe JDK internal API (jdk.unsupported)
org.marlin.pisces.OffHeapArray → sun.misc.Unsafe JDK internal API (jdk.unsupported)
org.marlin.pisces.OffHeapArray$1 → sun.misc.Unsafe JDK internal API (jdk.unsupported)
org.marlin.pisces.Renderer → sun.awt.geom.PathConsumer2D JDK internal API (java.desktop)
org.marlin.pisces.Renderer → sun.misc.Unsafe JDK internal API (jdk.unsupported)
org.marlin.pisces.Stroker → sun.awt.geom.PathConsumer2D JDK internal API (java.desktop)
org.marlin.pisces.Stroker$PolyStack → sun.awt.geom.PathConsumer2D JDK internal API (java.desktop)
org.marlin.pisces.TransformingPathConsumer2D → sun.awt.geom.PathConsumer2D JDK internal API (java.desktop)
org.marlin.pisces.TransformingPathConsumer2D$DeltaScaleFilter → sun.awt.geom.PathConsumer2D JDK internal API (java.desktop)
org.marlin.pisces.TransformingPathConsumer2D$DeltaTransformFilter → sun.awt.geom.PathConsumer2D JDK internal API (java.desktop)
org.marlin.pisces.TransformingPathConsumer2D$Path2DWrapper → sun.awt.geom.PathConsumer2D JDK internal API (java.desktop)
metrics-core-3.0.2.jar → jdk.unsupported
com.codahale.metrics.Striped64 → sun.misc.Unsafe JDK internal API (jdk.unsupported)
com.codahale.metrics.Striped64$1 → sun.misc.Unsafe JDK internal API (jdk.unsupported)
com.codahale.metrics.Striped64$Cell → sun.misc.Unsafe JDK internal API (jdk.unsupported)
spring-core-4.3.18.RELEASE.jar → jdk.unsupported
org.springframework.objenesis.instantiator.sun.UnsafeFactoryInstantiator → sun.misc.Unsafe JDK internal API (jdk.unsupported)
org.springframework.objenesis.instantiator.util.ClassDefinitionUtils → sun.misc.Unsafe JDK internal API (jdk.unsupported)
org.springframework.objenesis.instantiator.util.UnsafeUtils → sun.misc.Unsafe JDK internal API (jdk.unsupported)
spring-ldap-core-2.3.2.RELEASE.jar → java.naming
org.springframework.ldap.core.support.AbstractContextSource → com.sun.jndi.ldap.LdapCtxFactory JDK internal API (java.naming)
xom-1.1.jar → java.xml
nu.xom.JDK15XML1_0Parser → com.sun.org.apache.xerces.internal.parsers.DTDConfiguration JDK internal API (java.xml)
nu.xom.JDK15XML1_0Parser → com.sun.org.apache.xerces.internal.parsers.SAXParser JDK internal API (java.xml)
nu.xom.JDK15XML1_0Parser → com.sun.org.apache.xerces.internal.util.SecurityManager JDK internal API (java.xml)
nu.xom.JDK15XML1_0Parser → com.sun.org.apache.xerces.internal.xni.parser.XMLParserConfiguration JDK internal API (java.xml)
xstream-1.4.10.jar → jdk.unsupported
com.thoughtworks.xstream.converters.reflection.SunLimitedUnsafeReflectionProvider → sun.misc.Unsafe JDK internal API (jdk.unsupported)
com.thoughtworks.xstream.converters.reflection.SunUnsafeReflectionProvider → sun.misc.Unsafe JDK internal API (jdk.unsupported)

Warning: JDK internal APIs are unsupported and private to JDK implementation that are
subject to be removed or changed incompatibly and could break your application.
Please modify your code to eliminate dependence on any JDK internal APIs.
For the most recent update on JDK internal API replacements, please check:
https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool

JDK Internal API Suggested Replacement

com.sun.image.codec.jpeg.ImageFormatException Use javax.imageio @since 1.4
com.sun.image.codec.jpeg.JPEGCodec Use javax.imageio @since 1.4
com.sun.image.codec.jpeg.JPEGDecodeParam Use javax.imageio @since 1.4
com.sun.image.codec.jpeg.JPEGEncodeParam Use javax.imageio @since 1.4
com.sun.image.codec.jpeg.JPEGImageDecoder Use javax.imageio @since 1.4
com.sun.image.codec.jpeg.JPEGImageEncoder Use javax.imageio @since 1.4
com.sun.image.codec.jpeg.JPEGQTable Use javax.imageio @since 1.4
sun.awt.image.codec.JPEGParam Use javax.imageio @since 1.4
sun.misc.Unsafe See http://openjdk.java.net/jeps/260
sun.security.action.GetPropertyAction Use java.security.PrivilegedAction @since 1.1

I’ve grayed out parts that are dealt with in upstream projects, leaving the ones that seem to be specific to GeoServer.
We have pointers to both libraries we are using, and GeoServer modules.

Cheers
Andrea

···

GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it ------------------------------------------------------- Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.

jive · October 6, 2018, 2:49am

Thanks Andrea added this list to the google spreadsheet and started looking at what can be done.

Unless I am missing something much of list can be addressed by adding activations - like --add-modules jdk.unsupported

···

–
Jody Garnett

Andrea_Aime4 · October 6, 2018, 8:55am

Hi Jody,
yes, that could be done, and will likely be required for modularized applications… but if we at all can, I’d like to avoid it.

In terms of objective for the sprint I’d like to see (in this order):

Everything in our stack (jaitools, jai-ext, imageio-ext, geotools, geowebcache, geoserver) builds and run without any flag added, off the classpath (it’s ok to have warnings). This will allow us to get JDK 11 builds going.
Get as much as possible build and run without warnings (I’m guessing some bits will be too hard to migrate, we’ll document them). I don’t have a great plan on how to automate this, suggestions?
Add automatic module descriptors, eliminate split packages in library projects (so with the exclusion of gwc and gs), make sure we can run a true module app depending on the automatic modules (idea, we could use the demo module, already depending on many of the others, and make that one a true module?). Adjust imports and the like as needed in all projects (fun for the whole family here), try to collect migration scripts to help others do the same.
Swich gt-api away from using org.opengis package, upgrade everything else to follow (OMG, the EMF modules depend on that, does it mean we have to re-generate them? that will require the Eclipse version that was used to create them, and a lot of cursing)
Ideally, it would be nice if we could stop and merge on master as soon as each of the step is complete, this would ensure we get something really done, shows progress, and it hits the build server and the CITE tests (we can update the builds as we go to build both on jdk8 and 11).

Cheers
Andrea

···

Regards, Andrea Aime == GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it ------------------------------------------------------- Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.

Nuno_Oliveira1 · October 8, 2018, 11:09am

The scariest thing I have read so far (on all the discussions \ threads) around migrating to Java 11:

(OMG, the EMF modules depend on that, does it mean we have to re-generate them? that will require the Eclipse version that was used to create them, and a lot of cursing)

···

Note, I understand why we have EMF and why it was handled like that, it was the best option at the time.

Ideally, it would be nice if we could stop and merge on master as soon as each of the step is complete, this would ensure we get something really done, shows progress, and it hits the build server and the CITE tests (we can update the builds as we go to build both on jdk8 and 11).

+1 on this

On 10/06/2018 09:55 AM, Andrea Aime wrote:

Hi Jody,
yes, that could be done, and will likely be required for modularized applications… but if we at all can, I’d like to avoid it.

In terms of objective for the sprint I’d like to see (in this order):

Everything in our stack (jaitools, jai-ext, imageio-ext, geotools, geowebcache, geoserver) builds and run without any flag added, off the classpath (it’s ok to have warnings). This will allow us to get JDK 11 builds going.

Get as much as possible build and run without warnings (I’m guessing some bits will be too hard to migrate, we’ll document them). I don’t have a great plan on how to automate this, suggestions?

Add automatic module descriptors, eliminate split packages in library projects (so with the exclusion of gwc and gs), make sure we can run a true module app depending on the automatic modules (idea, we could use the demo module, already depending on many of the others, and make that one a true module?). Adjust imports and the like as needed in all projects (fun for the whole family here), try to collect migration scripts to help others do the same.

Swich gt-api away from using org.opengis package, upgrade everything else to follow (OMG, the EMF modules depend on that, does it mean we have to re-generate them? that will require the Eclipse version that was used to create them, and a lot of cursing)
Ideally, it would be nice if we could stop and merge on master as soon as each of the step is complete, this would ensure we get something really done, shows progress, and it hits the build server and the CITE tests (we can update the builds as we go to build both on jdk8 and 11).

Cheers
Andrea

On Sat, Oct 6, 2018 at 4:50 AM Jody Garnett <jody.garnett@anonymised.com> wrote:

Thanks Andrea added this list to the google spreadsheet and started looking at what can be done.

Unless I am missing something much of list can be addressed by adding activations - like --add-modules jdk.unsupported

–
Jody Garnett

On Sun, 30 Sep 2018 at 02:21, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi,
I am looking at internal API usage that we (likely) have to remove during the JDK 11 upgrade effort.

The jdeps tool can scan jars and find internal API usage, so I used it. I’ve already run it on jai-ext (no complaints),
imageio-ext (see results at https://github.com/geosolutions-it/imageio-ext/issues/172 ) and GeoTools (see mail
sent to geotools-devel).

Here are the results running it onto GeoServer (I’ve run assembly:attach, unpacked the WAR, then also unpacked all release
plugins into it, and run jdeps on the resulting WEB-INF/lib):

Warning: split package: java.sql jrt:/java.sql hatbox-1.0.b10.jar
Warning: split package: javax.transaction.xa jrt:/java.transaction.xa jta-1.1.jar
Warning: split package: javax.xml jrt:/java.xml stax-api-1.0.1.jar xml-apis-1.4.01.jar xml-apis-xerces-2.7.1.jar
Warning: split package: javax.xml.datatype jrt:/java.xml xml-apis-1.4.01.jar xml-apis-xerces-2.7.1.jar
Warning: split package: javax.xml.namespace jrt:/java.xml stax-api-1.0.1.jar xml-apis-1.4.01.jar xml-apis-xerces-2.7.1.jar xpp3-1.1.3.4.O.jar
Warning: split package: javax.xml.parsers jrt:/java.xml xml-apis-1.4.01.jar xml-apis-xerces-2.7.1.jar
Warning: split package: javax.xml.stream jrt:/java.xml stax-api-1.0.1.jar xml-apis-1.4.01.jar
Warning: split package: javax.xml.stream.events jrt:/java.xml stax-api-1.0.1.jar xml-apis-1.4.01.jar
Warning: split package: javax.xml.stream.util jrt:/java.xml stax-api-1.0.1.jar xml-apis-1.4.01.jar
Warning: split package: javax.xml.transform jrt:/java.xml xml-apis-1.4.01.jar xml-apis-xerces-2.7.1.jar
Warning: split package: javax.xml.transform.dom jrt:/java.xml xml-apis-1.4.01.jar xml-apis-xerces-2.7.1.jar
Warning: split package: javax.xml.transform.sax jrt:/java.xml xml-apis-1.4.01.jar xml-apis-xerces-2.7.1.jar
Warning: split package: javax.xml.transform.stax jrt:/java.xml xml-apis-1.4.01.jar
Warning: split package: javax.xml.transform.stream jrt:/java.xml xml-apis-1.4.01.jar xml-apis-xerces-2.7.1.jar
Warning: split package: javax.xml.validation jrt:/java.xml xml-apis-1.4.01.jar xml-apis-xerces-2.7.1.jar
Warning: split package: javax.xml.xpath jrt:/java.xml xml-apis-1.4.01.jar xml-apis-xerces-2.7.1.jar
Warning: split package: org.w3c.dom jrt:/java.xml xml-apis-1.4.01.jar xml-apis-xerces-2.7.1.jar xom-1.1.jar
Warning: split package: org.w3c.dom.bootstrap jrt:/java.xml xml-apis-1.4.01.jar xml-apis-xerces-2.7.1.jar
Warning: split package: org.w3c.dom.css jrt:/jdk.xml.dom xml-apis-1.4.01.jar xml-apis-xerces-2.7.1.jar
Warning: split package: org.w3c.dom.events jrt:/java.xml batik-ext-1.10.jar xml-apis-1.4.01.jar xml-apis-xerces-2.7.1.jar
Warning: split package: org.w3c.dom.html jrt:/jdk.xml.dom xercesImpl-2.11.0.jar xml-apis-1.4.01.jar xml-apis-xerces-2.7.1.jar
Warning: split package: org.w3c.dom.ls jrt:/java.xml xml-apis-1.4.01.jar xml-apis-xerces-2.7.1.jar
Warning: split package: org.w3c.dom.ranges jrt:/java.xml xml-apis-1.4.01.jar xml-apis-xerces-2.7.1.jar
Warning: split package: org.w3c.dom.stylesheets jrt:/jdk.xml.dom xml-apis-1.4.01.jar xml-apis-xerces-2.7.1.jar
Warning: split package: org.w3c.dom.traversal jrt:/java.xml xml-apis-1.4.01.jar xml-apis-xerces-2.7.1.jar
Warning: split package: org.w3c.dom.views jrt:/java.xml xml-apis-1.4.01.jar xml-apis-xerces-2.7.1.jar
Warning: split package: org.w3c.dom.xpath jrt:/jdk.xml.dom xml-apis-1.4.01.jar xml-apis-xerces-2.7.1.jar
Warning: split package: org.xml.sax jrt:/java.xml xml-apis-1.4.01.jar xml-apis-xerces-2.7.1.jar
Warning: split package: org.xml.sax.ext jrt:/java.xml xml-apis-1.4.01.jar xml-apis-xerces-2.7.1.jar
Warning: split package: org.xml.sax.helpers jrt:/java.xml xml-apis-1.4.01.jar xml-apis-xerces-2.7.1.jar
dom4j-1.6.1.jar → JDK removed internal API
org.dom4j.datatype.DatatypeAttribute → org.relaxng.datatype.DatatypeException JDK internal API (JDK removed internal API)
org.dom4j.datatype.DatatypeAttribute → org.relaxng.datatype.ValidationContext JDK internal API (JDK removed internal API)
org.dom4j.datatype.DatatypeElement → org.relaxng.datatype.DatatypeException JDK internal API (JDK removed internal API)
org.dom4j.datatype.DatatypeElement → org.relaxng.datatype.ValidationContext JDK internal API (JDK removed internal API)
org.dom4j.datatype.SchemaParser → org.relaxng.datatype.DatatypeException JDK internal API (JDK removed internal API)
org.dom4j.datatype.SchemaParser → org.relaxng.datatype.ValidationContext JDK internal API (JDK removed internal API)
ehcache-2.10.3.jar → jdk.unsupported
net.sf.ehcache.pool.sizeof.UnsafeSizeOf → sun.misc.Unsafe JDK internal API (jdk.unsupported)
freemarker-2.3.18.jar → java.xml
freemarker.ext.dom.SunInternalXalanXPathSupport → com.sun.org.apache.xml.internal.utils.PrefixResolver JDK internal API (java.xml)
freemarker.ext.dom.SunInternalXalanXPathSupport → com.sun.org.apache.xpath.internal.XPath JDK internal API (java.xml)
freemarker.ext.dom.SunInternalXalanXPathSupport → com.sun.org.apache.xpath.internal.XPathContext JDK internal API (java.xml)
freemarker.ext.dom.SunInternalXalanXPathSupport → com.sun.org.apache.xpath.internal.objects.XBoolean JDK internal API (java.xml)
freemarker.ext.dom.SunInternalXalanXPathSupport → com.sun.org.apache.xpath.internal.objects.XNodeSet JDK internal API (java.xml)
freemarker.ext.dom.SunInternalXalanXPathSupport → com.sun.org.apache.xpath.internal.objects.XNull JDK internal API (java.xml)
freemarker.ext.dom.SunInternalXalanXPathSupport → com.sun.org.apache.xpath.internal.objects.XNumber JDK internal API (java.xml)
freemarker.ext.dom.SunInternalXalanXPathSupport → com.sun.org.apache.xpath.internal.objects.XObject JDK internal API (java.xml)
freemarker.ext.dom.SunInternalXalanXPathSupport → com.sun.org.apache.xpath.internal.objects.XString JDK internal API (java.xml)
freemarker.ext.dom.SunInternalXalanXPathSupport$1 → com.sun.org.apache.xml.internal.utils.PrefixResolver JDK internal API (java.xml)
gs-platform-2.15-SNAPSHOT.jar → java.desktop
org.geoserver.platform.RenderingEngineStatus → sun.java2d.pipe.RenderingEngine JDK internal API (java.desktop)
gs-web-core-2.15-SNAPSHOT.jar → java.desktop
org.geoserver.web.admin.StatusPanel → sun.java2d.pipe.RenderingEngine JDK internal API (java.desktop)
gs-wms-2.15-SNAPSHOT.jar → java.xml
org.geoserver.wms.featureinfo.RasterLayerIdentifier → com.sun.org.apache.xml.internal.utils.XMLChar JDK internal API (java.xml)
gt-arcsde-21-SNAPSHOT.jar → java.desktop
org.geotools.arcsde.raster.info.RasterUtils → com.sun.imageio.plugins.common.BogusColorSpace JDK internal API (java.desktop)
gt-coverage-api-21-SNAPSHOT.jar → java.desktop
org.geotools.coverage.io.util.Utilities → sun.awt.OSInfo JDK internal API (java.desktop)
org.geotools.coverage.io.util.Utilities → sun.awt.OSInfo$OSType JDK internal API (java.desktop)
guava-25.1-jre.jar → jdk.unsupported
com.google.common.cache.Striped64 → sun.misc.Unsafe JDK internal API (jdk.unsupported)
com.google.common.cache.Striped64$1 → sun.misc.Unsafe JDK internal API (jdk.unsupported)
com.google.common.cache.Striped64$Cell → sun.misc.Unsafe JDK internal API (jdk.unsupported)
com.google.common.hash.LittleEndianByteArray$UnsafeByteArray → sun.misc.Unsafe JDK internal API (jdk.unsupported)
com.google.common.hash.LittleEndianByteArray$UnsafeByteArray$1 → sun.misc.Unsafe JDK internal API (jdk.unsupported)
com.google.common.hash.LittleEndianByteArray$UnsafeByteArray$2 → sun.misc.Unsafe JDK internal API (jdk.unsupported)
com.google.common.hash.LittleEndianByteArray$UnsafeByteArray$3 → sun.misc.Unsafe JDK internal API (jdk.unsupported)
com.google.common.hash.Striped64 → sun.misc.Unsafe JDK internal API (jdk.unsupported)
com.google.common.hash.Striped64$1 → sun.misc.Unsafe JDK internal API (jdk.unsupported)
com.google.common.hash.Striped64$Cell → sun.misc.Unsafe JDK internal API (jdk.unsupported)
com.google.common.primitives.UnsignedBytes$LexicographicalComparatorHolder$UnsafeComparator → sun.misc.Unsafe JDK internal API (jdk.unsupported)
com.google.common.primitives.UnsignedBytes$LexicographicalComparatorHolder$UnsafeComparator$1 → sun.misc.Unsafe JDK internal API (jdk.unsupported)
com.google.common.util.concurrent.AbstractFuture$UnsafeAtomicHelper → sun.misc.Unsafe JDK internal API (jdk.unsupported)
com.google.common.util.concurrent.AbstractFuture$UnsafeAtomicHelper$1 → sun.misc.Unsafe JDK internal API (jdk.unsupported)
gwc-wms-1.15-SNAPSHOT.jar → java.desktop
org.geowebcache.io.ImageEncoderImpl$WriteHelper$1 → com.sun.imageio.plugins.png.PNGImageWriter JDK internal API (java.desktop)
hazelcast-3.3.1.jar → jdk.unsupported
com.hazelcast.nio.UTFEncoderDecoder$UnsafeBasedCharArrayUtfWriter → sun.misc.Unsafe JDK internal API (jdk.unsupported)
com.hazelcast.nio.UnsafeHelper → sun.misc.Unsafe JDK internal API (jdk.unsupported)
com.hazelcast.nio.UnsafeHelper$1 → sun.misc.Unsafe JDK internal API (jdk.unsupported)
com.hazelcast.nio.serialization.UnsafeObjectDataInput → sun.misc.Unsafe JDK internal API (jdk.unsupported)
com.hazelcast.nio.serialization.UnsafeObjectDataOutput → sun.misc.Unsafe JDK internal API (jdk.unsupported)
imageio-ext-streams-1.1.25.jar → java.desktop
it.geosolutions.imageio.stream.input.spi.FileImageInputStreamExtImplSpi → com.sun.imageio.spi.FileImageInputStreamSpi JDK internal API (java.desktop)
it.geosolutions.imageio.stream.output.spi.FileImageOutputStreamExtImplSpi → com.sun.imageio.spi.FileImageOutputStreamSpi JDK internal API (java.desktop)
imageio-ext-utilities-1.1.25.jar → java.desktop
it.geosolutions.imageio.utilities.ImageIOUtilities → com.sun.imageio.plugins.common.BogusColorSpace JDK internal API (java.desktop)
jai_codec-1.1.3.jar → JDK removed internal API
jai_codec-1.1.3.jar → java.base
com.sun.media.jai.codecimpl.JPEGImage → com.sun.image.codec.jpeg.ImageFormatException JDK internal API (JDK removed internal API)
com.sun.media.jai.codecimpl.JPEGImage → com.sun.image.codec.jpeg.JPEGCodec JDK internal API (JDK removed internal API)
com.sun.media.jai.codecimpl.JPEGImage → com.sun.image.codec.jpeg.JPEGImageDecoder JDK internal API (JDK removed internal API)
com.sun.media.jai.codecimpl.JPEGImageEncoder → com.sun.image.codec.jpeg.JPEGCodec JDK internal API (JDK removed internal API)
com.sun.media.jai.codecimpl.JPEGImageEncoder → com.sun.image.codec.jpeg.JPEGEncodeParam JDK internal API (JDK removed internal API)
com.sun.media.jai.codecimpl.JPEGImageEncoder → com.sun.image.codec.jpeg.JPEGImageEncoder JDK internal API (JDK removed internal API)
com.sun.media.jai.codecimpl.JPEGImageEncoder → com.sun.image.codec.jpeg.JPEGQTable JDK internal API (JDK removed internal API)
com.sun.media.jai.codecimpl.PNMImage → sun.security.action.GetPropertyAction JDK internal API (java.base)
com.sun.media.jai.codecimpl.PNMImageEncoder → sun.security.action.GetPropertyAction JDK internal API (java.base)
com.sun.media.jai.codecimpl.TIFFImage → com.sun.image.codec.jpeg.JPEGCodec JDK internal API (JDK removed internal API)
com.sun.media.jai.codecimpl.TIFFImage → com.sun.image.codec.jpeg.JPEGDecodeParam JDK internal API (JDK removed internal API)
com.sun.media.jai.codecimpl.TIFFImage → com.sun.image.codec.jpeg.JPEGImageDecoder JDK internal API (JDK removed internal API)
com.sun.media.jai.codecimpl.TIFFImageEncoder → com.sun.image.codec.jpeg.JPEGCodec JDK internal API (JDK removed internal API)
com.sun.media.jai.codecimpl.TIFFImageEncoder → com.sun.image.codec.jpeg.JPEGEncodeParam JDK internal API (JDK removed internal API)
com.sun.media.jai.codecimpl.TIFFImageEncoder → com.sun.image.codec.jpeg.JPEGImageEncoder JDK internal API (JDK removed internal API)
com.sun.media.jai.codecimpl.fpx.FPXImage → com.sun.image.codec.jpeg.JPEGCodec JDK internal API (JDK removed internal API)
com.sun.media.jai.codecimpl.fpx.FPXImage → com.sun.image.codec.jpeg.JPEGDecodeParam JDK internal API (JDK removed internal API)
com.sun.media.jai.codecimpl.fpx.FPXImage → com.sun.image.codec.jpeg.JPEGImageDecoder JDK internal API (JDK removed internal API)
jai_core-1.1.3.jar → JDK removed internal API
jai_core-1.1.3.jar → java.desktop
com.sun.media.jai.opimage.IIPResolutionOpImage → com.sun.image.codec.jpeg.JPEGCodec JDK internal API (JDK removed internal API)
com.sun.media.jai.opimage.IIPResolutionOpImage → com.sun.image.codec.jpeg.JPEGDecodeParam JDK internal API (JDK removed internal API)
com.sun.media.jai.opimage.IIPResolutionOpImage → com.sun.image.codec.jpeg.JPEGImageDecoder JDK internal API (JDK removed internal API)
com.sun.media.jai.tilecodec.JPEGTileDecoder → com.sun.image.codec.jpeg.JPEGCodec JDK internal API (JDK removed internal API)
com.sun.media.jai.tilecodec.JPEGTileDecoder → com.sun.image.codec.jpeg.JPEGDecodeParam JDK internal API (JDK removed internal API)
com.sun.media.jai.tilecodec.JPEGTileDecoder → com.sun.image.codec.jpeg.JPEGImageDecoder JDK internal API (JDK removed internal API)
com.sun.media.jai.tilecodec.JPEGTileDecoder → com.sun.image.codec.jpeg.JPEGQTable JDK internal API (JDK removed internal API)
com.sun.media.jai.tilecodec.JPEGTileEncoder → com.sun.image.codec.jpeg.JPEGCodec JDK internal API (JDK removed internal API)
com.sun.media.jai.tilecodec.JPEGTileEncoder → com.sun.image.codec.jpeg.JPEGEncodeParam JDK internal API (JDK removed internal API)
com.sun.media.jai.tilecodec.JPEGTileEncoder → com.sun.image.codec.jpeg.JPEGImageEncoder JDK internal API (JDK removed internal API)
com.sun.media.jai.tilecodec.JPEGTileEncoder → com.sun.image.codec.jpeg.JPEGQTable JDK internal API (JDK removed internal API)
com.sun.media.jai.tilecodec.JPEGTileEncoder → sun.awt.image.codec.JPEGParam JDK internal API (JDK removed internal API)
javax.media.jai.RasterAccessor → sun.awt.image.BytePackedRaster JDK internal API (java.desktop)
jai_imageio-1.1.jar → java.base
com.sun.media.imageioimpl.plugins.pnm.PNMImageReader → sun.security.action.GetPropertyAction JDK internal API (java.base)
com.sun.media.imageioimpl.plugins.pnm.PNMImageWriter → sun.security.action.GetPropertyAction JDK internal API (java.base)
marlin-0.7.5-Unsafe.jar → java.base
marlin-0.7.5-Unsafe.jar → java.desktop
marlin-0.7.5-Unsafe.jar → jdk.unsupported
org.marlin.geom.Path2D → sun.awt.geom.Curve JDK internal API (java.desktop)
org.marlin.geom.Path2D$Double → sun.awt.geom.Curve JDK internal API (java.desktop)
org.marlin.geom.Path2D$Float → sun.awt.geom.Curve JDK internal API (java.desktop)
org.marlin.pisces.CollinearSimplifier → sun.awt.geom.PathConsumer2D JDK internal API (java.desktop)
org.marlin.pisces.DMarlinRenderingEngine → sun.awt.geom.PathConsumer2D JDK internal API (java.desktop)
org.marlin.pisces.DMarlinRenderingEngine → sun.java2d.pipe.AATileGenerator JDK internal API (java.desktop)
org.marlin.pisces.DMarlinRenderingEngine → sun.java2d.pipe.Region JDK internal API (java.desktop)
org.marlin.pisces.DMarlinRenderingEngine → sun.java2d.pipe.RenderingEngine JDK internal API (java.desktop)
org.marlin.pisces.DMarlinRenderingEngine → sun.security.action.GetPropertyAction JDK internal API (java.base)
org.marlin.pisces.DRenderer → sun.misc.Unsafe JDK internal API (jdk.unsupported)
org.marlin.pisces.DRendererContext$PathConsumer2DAdapter → sun.awt.geom.PathConsumer2D JDK internal API (java.desktop)
org.marlin.pisces.Dasher → sun.awt.geom.PathConsumer2D JDK internal API (java.desktop)
org.marlin.pisces.MarlinCache → sun.misc.Unsafe JDK internal API (jdk.unsupported)
org.marlin.pisces.MarlinProperties → sun.security.action.GetPropertyAction JDK internal API (java.base)
org.marlin.pisces.MarlinRenderingEngine → sun.awt.geom.PathConsumer2D JDK internal API (java.desktop)
org.marlin.pisces.MarlinRenderingEngine → sun.java2d.pipe.AATileGenerator JDK internal API (java.desktop)
org.marlin.pisces.MarlinRenderingEngine → sun.java2d.pipe.Region JDK internal API (java.desktop)
org.marlin.pisces.MarlinRenderingEngine → sun.java2d.pipe.RenderingEngine JDK internal API (java.desktop)
org.marlin.pisces.MarlinRenderingEngine → sun.security.action.GetPropertyAction JDK internal API (java.base)
org.marlin.pisces.MarlinTileGenerator → sun.java2d.pipe.AATileGenerator JDK internal API (java.desktop)
org.marlin.pisces.MarlinTileGenerator → sun.misc.Unsafe JDK internal API (jdk.unsupported)
org.marlin.pisces.OffHeapArray → sun.misc.Unsafe JDK internal API (jdk.unsupported)
org.marlin.pisces.OffHeapArray$1 → sun.misc.Unsafe JDK internal API (jdk.unsupported)
org.marlin.pisces.Renderer → sun.awt.geom.PathConsumer2D JDK internal API (java.desktop)
org.marlin.pisces.Renderer → sun.misc.Unsafe JDK internal API (jdk.unsupported)
org.marlin.pisces.Stroker → sun.awt.geom.PathConsumer2D JDK internal API (java.desktop)
org.marlin.pisces.Stroker$PolyStack → sun.awt.geom.PathConsumer2D JDK internal API (java.desktop)
org.marlin.pisces.TransformingPathConsumer2D → sun.awt.geom.PathConsumer2D JDK internal API (java.desktop)
org.marlin.pisces.TransformingPathConsumer2D$DeltaScaleFilter → sun.awt.geom.PathConsumer2D JDK internal API (java.desktop)
org.marlin.pisces.TransformingPathConsumer2D$DeltaTransformFilter → sun.awt.geom.PathConsumer2D JDK internal API (java.desktop)
org.marlin.pisces.TransformingPathConsumer2D$Path2DWrapper → sun.awt.geom.PathConsumer2D JDK internal API (java.desktop)
metrics-core-3.0.2.jar → jdk.unsupported
com.codahale.metrics.Striped64 → sun.misc.Unsafe JDK internal API (jdk.unsupported)
com.codahale.metrics.Striped64$1 → sun.misc.Unsafe JDK internal API (jdk.unsupported)
com.codahale.metrics.Striped64$Cell → sun.misc.Unsafe JDK internal API (jdk.unsupported)
spring-core-4.3.18.RELEASE.jar → jdk.unsupported
org.springframework.objenesis.instantiator.sun.UnsafeFactoryInstantiator → sun.misc.Unsafe JDK internal API (jdk.unsupported)
org.springframework.objenesis.instantiator.util.ClassDefinitionUtils → sun.misc.Unsafe JDK internal API (jdk.unsupported)
org.springframework.objenesis.instantiator.util.UnsafeUtils → sun.misc.Unsafe JDK internal API (jdk.unsupported)
spring-ldap-core-2.3.2.RELEASE.jar → java.naming
org.springframework.ldap.core.support.AbstractContextSource → com.sun.jndi.ldap.LdapCtxFactory JDK internal API (java.naming)
xom-1.1.jar → java.xml
nu.xom.JDK15XML1_0Parser → com.sun.org.apache.xerces.internal.parsers.DTDConfiguration JDK internal API (java.xml)
nu.xom.JDK15XML1_0Parser → com.sun.org.apache.xerces.internal.parsers.SAXParser JDK internal API (java.xml)
nu.xom.JDK15XML1_0Parser → com.sun.org.apache.xerces.internal.util.SecurityManager JDK internal API (java.xml)
nu.xom.JDK15XML1_0Parser → com.sun.org.apache.xerces.internal.xni.parser.XMLParserConfiguration JDK internal API (java.xml)
xstream-1.4.10.jar → jdk.unsupported
com.thoughtworks.xstream.converters.reflection.SunLimitedUnsafeReflectionProvider → sun.misc.Unsafe JDK internal API (jdk.unsupported)
com.thoughtworks.xstream.converters.reflection.SunUnsafeReflectionProvider → sun.misc.Unsafe JDK internal API (jdk.unsupported)

Warning: JDK internal APIs are unsupported and private to JDK implementation that are
subject to be removed or changed incompatibly and could break your application.
Please modify your code to eliminate dependence on any JDK internal APIs.
For the most recent update on JDK internal API replacements, please check:
https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool

JDK Internal API Suggested Replacement

com.sun.image.codec.jpeg.ImageFormatException Use javax.imageio @since 1.4
com.sun.image.codec.jpeg.JPEGCodec Use javax.imageio @since 1.4
com.sun.image.codec.jpeg.JPEGDecodeParam Use javax.imageio @since 1.4
com.sun.image.codec.jpeg.JPEGEncodeParam Use javax.imageio @since 1.4
com.sun.image.codec.jpeg.JPEGImageDecoder Use javax.imageio @since 1.4
com.sun.image.codec.jpeg.JPEGImageEncoder Use javax.imageio @since 1.4
com.sun.image.codec.jpeg.JPEGQTable Use javax.imageio @since 1.4
sun.awt.image.codec.JPEGParam Use javax.imageio @since 1.4
sun.misc.Unsafe See http://openjdk.java.net/jeps/260
sun.security.action.GetPropertyAction Use java.security.PrivilegedAction @since 1.1

I’ve grayed out parts that are dealt with in upstream projects, leaving the ones that seem to be specific to GeoServer.
We have pointers to both libraries we are using, and GeoServer modules.

Cheers
Andrea

==

GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it ------------------------------------------------------- Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–

Regards, Andrea Aime == GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it ------------------------------------------------------- Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.
_______________________________________________
Geoserver-devel mailing list
[Geoserver-devel@lists.sourceforge.net](mailto:Geoserver-devel@lists.sourceforge.net)
[https://lists.sourceforge.net/lists/listinfo/geoserver-devel](https://lists.sourceforge.net/lists/listinfo/geoserver-devel)

-- 
Regards,
Nuno Oliveira
==
GeoServer Professional Services from the experts! 
Visit [http://goo.gl/it488V](http://goo.gl/it488V) for more information.
==

Nuno Miguel Carvalho Oliveira
@nmcoliveira
Software Engineer

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax:      +39 0584 1660272

[http://www.geo-solutions.it](http://www.geo-solutions.it)
[http://twitter.com/geosolutions_it](http://twitter.com/geosolutions_it)

-------------------------------------------------------

Con riferimento alla normativa sul trattamento dei dati 
personali (Reg. UE 2016/679 - Regolamento generale sulla 
protezione dei dati “GDPR”), si precisa che ogni 
circostanza inerente alla presente email (il suo contenuto, 
gli eventuali allegati, etc.) è un dato la cui conoscenza 
è riservata al/i solo/i destinatario/i indicati dallo 
scrivente. Se il messaggio Le è giunto per errore, è 
tenuta/o a cancellarlo, ogni altra operazione è illecita. 
Le sarei comunque grato se potesse darmene notizia.

This email is intended only for the person or entity to 
which it is addressed and may contain information that 
is privileged, confidential or otherwise protected from 
disclosure. We remind that - as provided by European 
Regulation 2016/679 “GDPR” - copying, dissemination or 
use of this e-mail or the information herein by anyone 
other than the intended recipient is prohibited. If you 
have received this email by mistake, please notify 
us immediately by telephone or e-mail.

jive · October 9, 2018, 6:26pm

This is what I would like to cover for planning and priorities also.

Some feedback inline:

In terms of objective for the sprint I’d like to see (in this order):

Everything in our stack (jaitools, jai-ext, imageio-ext, geotools, geowebcache, geoserver) builds and run without any flag added, off the classpath (it’s ok to have warnings). This will allow us to get JDK 11 builds going.

I am not sure if this is possible, I think the flags are required to run in Java 11 … unless: There a very interesting middle ground maven example where Java 11 is used to compile module-info.java and Java 8 is used to compile everything else. This would allow us to include a module-info.java activating the modules without flags. We could even limit this to a geotools “base jar” that contains this module-info.java acting the required sections of the JRE.

Previously I have assumed building with Java 8 only and had not suggested the above.

Get as much as possible build and run without warnings (I’m guessing some bits will be too hard to migrate, we’ll document them). I don’t have a great plan on how to automate this, suggestions?

This was the reason for the high body count in sprint planning, I do not think we can automate this goal.

Add automatic module descriptors, eliminate split packages in library projects (so with the exclusion of gwc and gs), make sure we can run a true module app depending on the automatic modules (idea, we could use the demo module, already depending on many of the others, and make that one a true module?). Adjust imports and the like as needed in all projects (fun for the whole family here), try to collect migration scripts to help others do the same.

Very much agreed and was also going to suggest geotools “demo” act as a module (maybe even being broken up).
I strongly suggest we repackage gs and gwc codebase at this time also.

Swich gt-api away from using org.opengis package, upgrade everything else to follow (OMG, the EMF modules depend on that, does it mean we have to re-generate them? that will require the Eclipse version that was used to create them, and a lot of cursing)

I would prefer to cover this in the previous step so that the gt codebase is “done”.
Updating EMF modules is going to be difficult, but I think we are stuck going in there anyways with all the code being repackaged.

Ideally, it would be nice if we could stop and merge on master as soon as each of the step is complete, this would ensure we get something really done, shows progress, and it hits the build server and the CITE tests (we can update the builds as we go to build both on jdk8 and 11).

I had hoped that we could do some of these in parallel, example spring 5 update happening and landing on master, while geotools is repackaged. Then merge in geotools repackage, running the “sed scripts” to update the gwc and gs codebase as part of merging the gt change.

tbarsballe · October 9, 2018, 6:47pm

In terms of objective for the sprint I’d like to see (in this order):

Everything in our stack (jaitools, jai-ext, imageio-ext, geotools, geowebcache, geoserver) builds and run without any flag added, off the classpath (it’s ok to have warnings). This will allow us to get JDK 11 builds going.

I am not sure if this is possible, I think the flags are required to run in Java 11 … unless: There a very interesting middle ground maven example where Java 11 is used to compile module-info.java and Java 8 is used to compile everything else. This would allow us to include a module-info.java activating the modules without flags. We could even limit this to a geotools “base jar” that contains this module-info.java acting the required sections of the JRE.

Note that Java 11 supports much fewer flags than Java 9 did. While I’m not certain its possible, getting GeoServer to run on JDK 11 with no flags does seem like something we should be aiming for.

Ideally, it would be nice if we could stop and merge on master as soon as each of the step is complete, this would ensure we get something really done, shows progress, and it hits the build server and the CITE tests (we can update the builds as we go to build both on jdk8 and 11).

I had hoped that we could do some of these in parallel, example spring 5 update happening and landing on master, while geotools is repackaged. Then merge in geotools repackage, running the “sed scripts” to update the gwc and gs codebase as part of merging the gt change.

I agree stuff like the Spring update could be completed in parallel with some of the other geotools tasks.

As a reminder, we do have the geotools-java9 , geowebcache-java9, and geoserver-java9 jenkins jobs that were set up for testing Java 9. These could pretty easily be updated to use Java 11, and run against our dev branch for the duration of the sprint. Periodic merges to master still sound useful, but those jobs would be a good indicator of how far along things are.

Torben

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Andrea_Aime4 · October 11, 2018, 7:45am

In terms of objective for the sprint I’d like to see (in this order):

Everything in our stack (jaitools, jai-ext, imageio-ext, geotools, geowebcache, geoserver) builds and run without any flag added, off the classpath (it’s ok to have warnings). This will allow us to get JDK 11 builds going.

I am not sure if this is possible, I think the flags are required to run in Java 11 …

Where is that thinking coming from? From what I read Java 11 is still quite permissive from the classpath (as written above, first object, work off the classpath, ok to have warnings), one just needs to add
jaxb and activation deps explicitly in the pom files.
In the spirit of “how hard can it be” I’ve build a few projects with java 11 (with tests, so that includes some runtime testing too):

jai-ext just builds, no changes required
imageio-ext requires adding jaxb and activation dependencies to one module, trivial changes at https://github.com/geosolutions-it/imageio-ext/pull/176
geotools, removed the “–add-modules”, added jaxb and activation to imagemosaic and solr, one odd test failure that I have ignored for the moment (it’s about checking one init clause), some differences in rendering that I still need to look into, but PR (just for the sake of having a look, please don’t merge) here: https://github.com/geotools/geotools/pull/2100
One dev, three projects, less than a hour to get some basic build going without any flag… I’ll call your “not sure if this is possible” and raise a “pretty doable”.

I did not, however, manage to build GeoServer yet (the time I had available this morning before working hours just finished…), there is a class init failure in SLDHandler killing the build at gs-main, could not debug it yet.
But with a little bit more effort, this first step might be solved before we even start the sprint (I’ll have another look in weekends before the sprint).

Of course there are warnings, although difficult to spot in the build output. For example:

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.geotools.resources.NIOUtilities (file:/home/aaime/.m2/repository/org/geotools/gt-metadata/21-SNAPSHOT/gt-metadata-21-SNAPSHOT.jar) to method java.nio.DirectByteBuffer.cleaner()
WARNING: Please consider reporting this to the maintainers of org.geotools.resources.NIOUtilities
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release

The sad outcome of the experiment are build times… with java 8 I build in 4:30 (with a -T8 on a 8 core CPU),

on java 11 it takes 7+ minutes (holy cow!)

Get as much as possible build and run without warnings (I’m guessing some bits will be too hard to migrate, we’ll document them). I don’t have a great plan on how to automate this, suggestions?

This was the reason for the high body count in sprint planning, I do not think we can automate this goal.

Agreed

Add automatic module descriptors, eliminate split packages in library projects (so with the exclusion of gwc and gs), make sure we can run a true module app depending on the automatic modules (idea, we could use the demo module, already depending on many of the others, and make that one a true module?). Adjust imports and the like as needed in all projects (fun for the whole family here), try to collect migration scripts to help others do the same.

Very much agreed and was also going to suggest geotools “demo” act as a module (maybe even being broken up).
I strongly suggest we repackage gs and gwc codebase at this time also.

I don’t disagree here, but let’s do it in waves, first repackage and modularize geotools, then gwc, then gs (in this order, having everythig building and running at the end of each step).

Swich gt-api away from using org.opengis package, upgrade everything else to follow (OMG, the EMF modules depend on that, does it mean we have to re-generate them? that will require the Eclipse version that was used to create them, and a lot of cursing)

I would prefer to cover this in the previous step so that the gt codebase is “done”.

No, no, and no… it’s not required to run on JDK 11, we’ll do it once everything else is working. We can cut some time off the “running without warning” as I’m afraid it might
just not be feasible, let’s strive to remove as many warnings as possible, but don’t get too caught up if they originate from dependent libraries, that will likely solve itself.
This should make enough time to do geoapi switch towards the end. Suggestion, someone should try to figure out which Eclipse version we should use to rebuild the EMF
bindings, in my experience each of the EMF module needs its own blessed old Eclipse version to build at all (not all build with the same version).

Updating EMF modules is going to be difficult, but I think we are stuck going in there anyways with all the code being repackaged.

Maybe, maybe not. Repackaging the most core modules that EMF bindings depend onto will hopefully mostly mean moving classes between jars.
It’s the geoapi thing that’s going to break everything, and it’s not really required to build and run on Java 11, so let’s do it last.
Jody, I’m not kidding here, doing it “within the rest” is ill considered. I’m not interested in participating in the sprint, if you keep on pushing on doing it along with what is actually required to do it, I’m also going to downvote any proposal that binds switching GeoAPI as a “one package” with the actual JDK 11 building and running changes.

To be clear, I’m not against switching GeoAPI, I’m against doing it along with the other changes.
First build and run on JDK11, and then if actually have time (which I believe we’ll have, especially if some basic preparation is done in advance, but I’m managing risk here), switch geoapi out of existance.
Make no mistake, I’m sick of seeing geoapi it there too, the effort I’m going to put in to try to complete step 1 (build with warnings) before the sprint is also going into the direction of giving us enough time to do the geoapi switch.

Ideally, it would be nice if we could stop and merge on master as soon as each of the step is complete, this would ensure we get something really done, shows progress, and it hits the build server and the CITE tests (we can update the builds as we go to build both on jdk8 and 11).

I had hoped that we could do some of these in parallel, example spring 5 update happening and landing on master, while geotools is repackaged. Then merge in geotools repackage, running the “sed scripts” to update the gwc and gs codebase as part of merging the gt change.

That needs to be vetted carefully, but yes, I guess we can work on some depdencies upgrade while repackaging happens

Cheers
Andrea

···

GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it ------------------------------------------------------- Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.

jive · October 11, 2018, 9:48pm

Good discussion, comments inline, and I think we may done our strategy.

geotools, removed the “–add-modules”, added jaxb and activation to imagemosaic and solr, one odd test failure that I have ignored for the moment (it’s about checking one init clause), some differences in rendering that I still need to look into, but PR (just for the sake of having a look, please don’t merge) here: https://github.com/geotools/geotools/pull/2100

I really like those activation dependencies, the other examples I found online were far more complicated. Fixing the java docs also does not look too difficult.

One dev, three projects, less than a hour to get some basic build going without any flag… I’ll call your “not sure if this is possible” and raise a “pretty doable”.

That is great!

The sad outcome of the experiment are build times… with java 8 I build in 4:30 (with a -T8 on a 8 core CPU),

on java 11 it takes 7+ minutes (holy cow!)

That must of been a lot of warnings, or is the new compiler just slower?

I don’t disagree here, but let’s do it in waves, first repackage and modularize geotools, then gwc, then gs (in this order, having everythig building and running at the end of each step).

Yes, the more small “shippable” steps the better.

No, no, and no… it’s not required to run on JDK 11, we’ll do it once everything else is working. We can cut some time off the “running without warning” as I’m afraid it might just not be feasible, let’s strive to remove as many warnings as possible, but don’t get too caught up if they originate from dependent libraries, that will likely solve itself.

This should make enough time to do geoapi switch towards the end. Suggestion, someone should try to figure out which Eclipse version we should use to rebuild the EMF bindings, in my experience each of the EMF module needs its own blessed old Eclipse version to build at all (not all build with the same version).

I have a bunch of the old eclipse versions on hand.

Maybe, maybe not. Repackaging the most core modules that EMF bindings depend onto will hopefully mostly mean moving classes between jars.

Okay I can see that, we really only care about api change, the implementations inside the generated code were never generated and can be edited to reflect any changes made.

I expect that some implementations will change package, and some methods will change from “package visible” to public, but neither of these would effect EMF method signatures.

To be clear, I’m not against switching GeoAPI, I’m against doing it along with the other changes.

Thanks for explaining how that can work.

I had hoped that we could do some of these in parallel, example spring 5 update happening and landing on master, while geotools is repackaged. Then merge in geotools repackage, running the “sed scripts” to update the gwc and gs codebase as part of merging the gt change.

That needs to be vetted carefully, but yes, I guess we can work on some depdencies upgrade while repackaging happens.

Any other good ideas on how to work across timezones and teams? And we should start making a list of participants to have ready for “day 1”.

Andrea_Aime4 · October 12, 2018, 6:42am

Good discussion, comments inline, and I think we may done our strategy.

geotools, removed the “–add-modules”, added jaxb and activation to imagemosaic and solr, one odd test failure that I have ignored for the moment (it’s about checking one init clause), some differences in rendering that I still need to look into, but PR (just for the sake of having a look, please don’t merge) here: https://github.com/geotools/geotools/pull/2100

I really like those activation dependencies, the other examples I found online were far more complicated. Fixing the java docs also does not look too difficult.

I don’t think e we really need the doclet anymore, do we? Haven’t used them in such a long time… I’d rather throw away the doclet
and clean up the special comments it was using in the source code (could be another relatively easy to automate mass change).

with java 8 I build in 4:30 (with a -T8 on a 8 core CPU),

on java 11 it takes 7+ minutes (holy cow!)

That must of been a lot of warnings, or is the new compiler just slower?

No idea, did not check, but it’s something that we want to investigate, the time increase is just insane and going to badly affect our
productivity.

That needs to be vetted carefully, but yes, I guess we can work on some depdencies upgrade while repackaging happens.

Any other good ideas on how to work across timezones and teams? And we should start making a list of participants to have ready for “day 1”.

Work across timezones can be beneficial or detrimental, depends on how we plan it.
We do have an hour or two of overlap at the end of european day/start of west coast day, that we can use to synch up.
What is important is that when one group gets close to end of day, whatever they did is either completely isolated,
or finished and committed, but we must not allow work in progress that would keep the other team hanging.
In case there is WIP that would stop the other team progress I’d recommend the person working on it to commit
on a visible branch on the project repo, and find someone in the other team that can take it over and bring it to
completion, and use that overlap time to talk and pass over whatever knowledge is needed to do that.
However, that will work only on the EU->CA switch, the other way around, maybe send mails with the description?
Since we are distributed we’ll also need some central place (jira? gdocs spreadsheet?) where there are all the tasks and a clear vision
of who’s working on what.

CheersAndrea

···

== GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it ------------------------------------------------------- Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.

Andrea_Aime4 · October 13, 2018, 9:03am

Compiler seems slower, jdk 8 builds geotools in 2:20 without tests on jdk8, but takes 3:35 in the same conditions on jdk 11… pff…
However that means there is another ~1:30 lost running tests… it just seems slower overall

Cheers
Andrea

···

GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it ------------------------------------------------------- Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.

jive · October 13, 2018, 5:07pm

I wonder if the oracle jdk 11 compiler is faster? It is legit to use that for development (just not production).

···

–
Jody Garnett

Andrea_Aime4 · October 13, 2018, 7:18pm

I would be surprised if it did but worth trying anyways. Do you have time? On my side I’ll give a kick to the openj9 variant of opening

Cheers
Andrea

Il sab 13 ott 2018, 19:08 Jody Garnett <jody.garnett@anonymised.com> ha scritto:

I wonder if the oracle jdk 11 compiler is faster? It is legit to use that for development (just not production).

–
Jody Garnett

On Sat, 13 Oct 2018 at 02:03, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Fri, Oct 12, 2018 at 8:42 AM Andrea Aime <andrea.aime@anonymised.com> wrote:

That must of been a lot of warnings, or is the new compiler just slower?

No idea, did not check, but it’s something that we want to investigate, the time increase is just insane and going to badly affect our
productivity.

Compiler seems slower, jdk 8 builds geotools in 2:20 without tests on jdk8, but takes 3:35 in the same conditions on jdk 11… pff…
However that means there is another ~1:30 lost running tests… it just seems slower overall

Cheers
Andrea

==

GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it ------------------------------------------------------- Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.

Brad_Hards · October 13, 2018, 9:19pm

The slower tests shouldn’t be affected by the compiler right?

So that means the runtime is noticeably slower. That isn’t good news. May need a plan follow-on activities for more performance-oriented stuff later. Maybe towards the end of the sprint we can work out a plan for tooling that could help on that.

Brad

From: Andrea Aime andrea.aime@anonymised.com
Sent: Saturday, 13 October 2018 8:04 PM
To: Jody Garnett jody.garnett@anonymised.com
Cc: Geoserver-devel geoserver-devel@anonymised.comceforge.net
Subject: Re: [Geoserver-devel] Java 11 upgrade, looking for internal API usage

On Fri, Oct 12, 2018 at 8:42 AM Andrea Aime <andrea.aime@anonymised.com> wrote:

That must of been a lot of warnings, or is the new compiler just slower?

No idea, did not check, but it’s something that we want to investigate, the time increase is just insane and going to badly affect our

productivity.

Compiler seems slower, jdk 8 builds geotools in 2:20 without tests on jdk8, but takes 3:35 in the same conditions on jdk 11… pff…

However that means there is another ~1:30 lost running tests… it just seems slower overall

Cheers

Andrea

==

GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it ------------------------------------------------------- Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.

Andrea_Aime4 · October 14, 2018, 8:19am

Hi Brad,
yes, that’s certainly cause of concern… I hope it’s due to the test JVMs having a short life span,
not allowing the JIT to do its job well, but it’s certainly something that we need to test…

Cheers
Andrea

···

Regards, Andrea Aime == GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it ------------------------------------------------------- Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.

jive · October 16, 2018, 5:13am

Performing an isolated test as I do not have all the checkouts, building epsg-hsql on geotools open_jdk branch:

mvn clean install -Dall -T8

Nothing statistically significant.

openjdk 11 2018-09-25

gt-metadata:
Total time: 17.631 s (Wall Clock)

Total time: 16.730 s (Wall Clock)

gt-epsg-hsql:
Total time: 28.384 s (Wall Clock)

Total time: 25.707 s (Wall Clock)

Total time: 25.640 s (Wall Clock)

java version “11” 2018-09-25

gt-metadata:
Total time: 17.267 s (Wall Clock)
Total time: 16.697 s (Wall Clock)

gt-epsg-hsql:

Total time: 26.806 s (Wall Clock)

Total time: 25.935 s (Wall Clock)

Total time: 26.173 s (Wall Clock)

Total time: 25.885 s (Wall Clock)

–
Jody Garnett

On Sat, 13 Oct 2018 at 12:18, Andrea Aime <andrea.aime@anonymised.com> wrote:

I would be surprised if it did but worth trying anyways. Do you have time? On my side I’ll give a kick to the openj9 variant of opening

Cheers
Andrea

Il sab 13 ott 2018, 19:08 Jody Garnett <jody.garnett@anonymised.com> ha scritto:

I wonder if the oracle jdk 11 compiler is faster? It is legit to use that for development (just not production).

–
Jody Garnett

On Sat, 13 Oct 2018 at 02:03, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Fri, Oct 12, 2018 at 8:42 AM Andrea Aime <andrea.aime@anonymised.com> wrote:

That must of been a lot of warnings, or is the new compiler just slower?

No idea, did not check, but it’s something that we want to investigate, the time increase is just insane and going to badly affect our
productivity.

Compiler seems slower, jdk 8 builds geotools in 2:20 without tests on jdk8, but takes 3:35 in the same conditions on jdk 11… pff…
However that means there is another ~1:30 lost running tests… it just seems slower overall

Cheers
Andrea

==

GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it ------------------------------------------------------- Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.