Re: [Geotools-devel] Java 11 upgrade: looking for internal API usage, GeoTools edition

It would also help to get some sponsorship, any sponsorship, ahead of asking OSGeo for assistance. We have a number of people flying who I hope we can offer to assist. Budget is here: [image: Google Spreadsheet] Java 2018 Code Sprint

Re: [Geotools-devel] Java 11 upgrade: looking for internal API usage, GeoTools edition

On Sun, Sep 30, 2018 at 2:21 PM Jody Garnett wrote: > I think we are all arriving at a similar place, it would be good to have a > planning session as the technical story come together. > Probably a good idea, I like having a clear plan and some criterias for "done" (e.g, being able to start and

[Geotools-devel] JDK 11 upgrade: split packages in GeoTools

Hi, I found this interesting tool reporting split packages, https://github.com/AdoptOpenJDK/jsplitpkgscan It does not work on jdk 8 or 11, but managed to run it on java 9, against a full binaries release directory of GeoTools, the result is interesting, and I hope, useful. Quite a bit of split pack

[Geotools-devel] Funny things trying to use GeoTools modules as automatic modules

Hi, I'm trying to use jdeps to get a full list of split packages, and while trying to run jdeps, I found some funny things that I was unaware of about the module system (unfortunately, found no way to actually use jdeps to list all split packages, it just reports the first error found and exists...

Re: [Geotools-devel] Java 11 upgrade: looking for internal API usage, GeoTools edition

I think we are all arriving at a similar place, it would be good to have a planning session as the technical story come together. - Running off the classpath is the min goal for the sprint. - I think geotools should also shoot for being usable on the module path. It is unclear to me if Java EE ap

Re: [Geotools-devel] Java 11 upgrade: looking for internal API usage, GeoTools edition

Hi Jody, depends on the focus of the sprint... if the target is to run off the classpath I believe all we need to is to care for the J2EE dependencies, which are not exposed anymore. However, if that was the focus, we could also ignore split packages. Going towards automatic modules, and then to p

Re: [Geotools-devel] Java 11 upgrade: looking for internal API usage, GeoTools edition

Thanks Andrea that is great, I thought there was going to continue to be a way to use “unsafe”? Found it - there is a jdk.unsupported module for popular internal packages (see https://www.azul.com/javas-magic-sauce/). I am not sure if the results of jdeps represent a blocker for jars on the class

Re: [Geotools-devel] Java 11 upgrade: looking for internal API usage, GeoTools edition

Ah, by the way, the jai-core and jai-imageio bits are grayed out, but they need to be deal with somewhere. I have the impression that the complaints are related to parts of those libs that we are not using, and maybe they can be solved by just manually re-packaging those jars with only the bits tha

[Geotools-devel] Java 11 upgrade: looking for internal API usage, GeoTools edition

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) and imageio-ext (see results at https://github.com/geosolutions-it/imageio-