[jts-dev] code sprint results for its project

[Jody Garnett <jody.garnett@xxxxxxxxx>]

As part of participating in the Bonn 2018 code sprint Rob had a look at getting JTS ready for the "jigsaw" module system introduced back in September for Java 9.

After this work JTS is ready to be used by applications making use of the "jigsaw" module system, although we do not yet use it ourselves.

For a great over view of what has been done, and what it means I will quote #274:

The Jigsaw module system requires that downstream users of JTS using the module system declare JTS as a module requirement. JTS acts as an automatic module, since it is not compiled with a module-info.java. Without this change, module users would have to reference the requirement for JTS by specifying the JAR name with the fully qualified version; this is unwieldy, will trigger necessary updates when updating the JTS version, and could cause errors when transitive dependencies rely on other versions of JTS.

This change utilizes the technique of putting the module name in the manifest, so that libraries declaring modules can refer to JTS with more friendly, version-less names, e.g.

// module-info.java for project org.foo.baz

module org.foo.baz {

  requires org.locationtech.jts;            // jts-core

  requires org.locationtech.jts.io;         // jts-io-common

  requires org.locationtech.jts.io.oracle;  // jts-io-ora

  requires org.locationtech.jts.io.sde;     // jts-io-sde

}

One thing we experimented with was confirming that this approach (adding a manifest entry which is ignored by Java 8, but respected by Java 9 "jigsaw") does correctly lock down each JTS jar as a module: The root its-core module publishes a classes into org.locationtech.jts.io - for KML and GML output. When we tried to add a org.locationtech.jts.ioJTSIOVersion class into jts-io-common it failed to load ... because two jars cannot publish into the same package.

References:

- http://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html 

--

Jody Garnett