Java 9 support for other profiles about unit-api HOT 9 CLOSED

As said in previous discussion, I strongly object against splitting the 27 kb unit-api-1.0.1-SNAPSHOT.jar into a bunch of smaller files.

• The gain of disk space is insignificant even for a micro-devices. Quite the opposite, it takes more space if a devices want the full API.
• There is no gain in memory usage since the JVM loads only the required classes. Quite the opposite, it consumes more memory because of additional java.lang.Module to be created.
• It makes no difference in the separation of concerns since the packages already provide such separation. If one module contains many packages, modules is a nice way to group related tasks together. But if we have "1 module = 1 package", then those modules bring nothing.

Inconvenient is module path pollution. It makes the module path longer (forcing users to think about more elements) and increase the risk of incompatible version numbers between different parts of the API. This is likely to happen for example when using two libraries depending on different versions of JSR-363: we may have library A loading java.measure.bla version 1.0 and library B who depends on java.measure.bla version 1.1 (fictive), but does not load it because it was already loaded by library A, and adds a java.measure.foo version 1.1 to it.

So splitting JSR-363 API in many modules increase maintenance cost for all users for no advantage I can see.

from unit-api.

Based on the modularity and optionality those who only need the smallest part of the API they shall be able to do that using dedicated modules. The "all" or "full" jar currently won't be split into those modules, thus there are separate modules like "java.measure.base" similar to the JDK. Those who need it ma use matching Maven profiles to build individual module jars. As described in https://docs.oracle.com/javase/9/tools/jlink.htm or https://jaxenter.de/java-9-tutorial-jlink-59103 (German)

from unit-api.

Shall we close this one, given the comment above?

from unit-api.

No it's not done yet. It is for extremely small IoT devices that need a minimal size and only use the "core/base" part of the JSR or base + format. By using JLink they're able to create an optimized app for their needs. We probably won't put those on MavenCentral, but we allow (and shall document in https://github.com/unitsofmeasurement/uom-guide like other things, e.g. "Compound" quantities) users who need this optimization to use the relevant profiles for that.

from unit-api.

The modules/core folder should be called modules/base, it's historically the name of the "Core Profile" but "base" blends better with how the JDK calls its most basic module.

from unit-api.

I'm a little bit confused about those profiles stuff. Are we talking about Maven modules or Jigsaw modules? I'm neutral about Maven profiles or modules, as long as it is possible for projects like GeoAPI to depends on a single JAR file for the full API from Maven Central.

However for Jigsaw modules, I would still like a single module in a single JAR for full API. But if we provide both a "single module for all" and "many nano-modules", we will have conflicts if those two distributions appear together on the module path (the JVM will refuse to start).

So is it only about Maven profiles (I have no objection to that), or is it also about Jigsaw modules?

from unit-api.

A bit of both. Jigsaw (based on how improved it for the "Full" module ;-) defines specific modules that are different from the "all" module, e.g. java.measure.base. At the moment the java.measure module does not consume those, although in theory it might some day, but so far it is small enough to avoid it. The Maven part uses the same classifier as we do in a few other places (mostly extension modules or demos) for platform or JDK specific elements. Therefore you must use something different either way, the Maven cordinates are unit-api-base or similar, never just unit-api, and the Jigsaw modul is e.g. java.measure.base. Whoever wants to use them will in most cases need a small scale implementation, the RI at least is not meant to use it. We'll probably demonstrate it with a slightly modified branch of https://github.com/unitsofmeasurement/uom-impl-enum. The important aspect is, those subsets of the API and small implementations can still pass the TCK in a particular profile like "Minimal" or "Format". Per definition the Java Module System only allows one package per module, so it makes no sense to declare "java.measure.quantity" and "java.measure.quantity.base" although we do have such profiles (they can be used without JPMS) This is mainly for Edge devices and we don't intend to put the Maven artifacts on MavenCentral at the moment.

Again we are talking about tiny devices at or below the Raspberry Pi Zero. Intel Curie (which I think may now also run Java) or similar chips/devices or https://github.com/siemens/meta-iot2000. These are Industrial IoT Boards and according to the GitHub repo it seems that some also run Java, but most are so constrained, you must create or use a slimmed-down JDK. And everything else is also tiny, so it matters, even if the API is 5kb, 12kb or ~40kb ;-)
And for some it even requires a 32-bit JDK which at least Java9/OpenJDK still offers. Thus it is more a "recipe" for tailor-made small modules on such environments, not an official distro on MavenCentral etc. but it should pass the TCK especially if someone wants to use it in Industrial IoT.

from unit-api.

https://maven.apache.org/plugins/maven-compiler-plugin/multirelease.html could be of help.

from unit-api.

The "profile jar" profiles make little sense and they mix the base module-info with another Automatic-Module-Name, so they were disregarded. While it would be too cumbersome to create a module-info for any of the module JARs beside "base" we use Automatic-Module-Name and smaller applications can combine the modules they need.

from unit-api.