Hello all
This is a report about ongoing work on Apache SIS. Since we upgraded
from Java 8 to Java 11, we take the opportunity for applying the Java
Platform Module System (JPMS) on the project. This work is done in a
separated repository for now and is a little bit long. Because it is a
big change, we would like to submit it for a vote when it will be ready.
The current state of the work can be seen there:
https://github.com/Geomatys/sis/commits/Jigsaw
A big part of the work is to change the way to load services and
resources. JPMS adds restrictions about what a module can load. It
become difficult to load a resource from another module, so we have to
modify the code in such a way that calls to java.util.ServiceLoader or
Class.getResourceAsStream(…) are done from the module that uses the
service or owns the resource, and not from an utility module. Commits
related to JPMS restrictions are:
* Upgrade Jakarta XML binding from version 2 to version 4 (done last
week by lazy consensus)
* Move a test class for avoiding package collision between two modules
* Add public static provider() methods (as expected by ServiceLoader)
* Remove the DefaultFactories class because it does not work in the
context of JPMS
* Move TemporalUtilities to the metadata modules since it is not
needed by the utility modules
* Remove deprecated dimension attributes from OperationMethod
* Remove the use of internal LazySet as a workaround for JDK 8 bug
since it is no longer necessary
* Delegate the loading of GeoAPI resources to GeoAPI itself
* Replace TypeRegistration.hasRenameFile(…) by a mechanism in which
the `TypeRegistration` subclass fetches itself the resource
* Remove usage of ResourceBundle.Control because it is not supported
in the context of named modules
* Add module-info.java files and migrate the declarations of service
providers
* Replace reflection by ServiceLoader uses in the `OptionalDependency
* Opens to JAXB implementations the classes to be marshalled in XML
In addition to above work for JPMS restrictions, we also have work
related to Maven restrictions. I found no way to take full advantage of
JPMS using Maven. Doing JPMS with Maven is not impossible, but forces
project to restrict themselves to a subset of JPMS advantages. We will
post a blog later giving more explanation. So for maximal benefit from
JPMS, it seems necessary to migrate to Gradle or other build system with
similar flexibility. The next commits listed below are for this migration:
* Remove the NetBeans Ant project, replaced (for now) by Maven
* Remove all Maven project files and documentation files which will
become obsolete
* Move directories of all source codes. The new directories are the
module names, as required by Java compiler when building a
modularized project
* Add Gradle build scripts
This branch gets frequent squashes and rebases, which is why the work is
done on a separated repository until it stabilize. While a significant
change in internal code and in the build system, those changes should
have few visible impact on the public API. So from the user point of
view, it should stay a minor SIS upgrade.
I will post more news when the work will be ready.
Martin
