Produce JPMS compatible artifacts

[tomprodehl]

Modular JAR or JMODS to support Java 11, the official long term support version for now.

[bjakke]

Hi,

Do you have an actual use-case for this?

Generally speaking I am aware of java 11 etc. related situations. However this is quite hard to implement properly without breaking existing things at the moment. Only thing that could be done easily is adding a 'Automatic-Module-Name' to the manifest. However even that is not a good solution (until #164), as currently there are some compiletime dependencies to jre internals (that are optional in runtime) and to my knowledge you should not really use the automatic module naming unless everything works properly within module restrictions.

Currenly this stack works on java 6-8, and on 11 with some warnings (#157) using classpath (I'm ignoring 9 and 10 as they are out of support already). Additionally it should be noted that it is only the Oracle JRE that is support for only 11+ starting from next year (and requires a subscription anyway...). There are other JRE/JDK vendors, e.g. https://adoptopenjdk.net/, for which at least java 8 is stated on the support page to be at least for 2023. Additionally this stack (and java) is also used outside of the mainstream platforms that do not follow the same schedule, e.g. in android, some PLCs and within some databases. Based on my understanding to make a complete foolproof support for JPMS and e.g. jlink (that uses it) requires in practice making the lib be 11(9+) only, as e.g. tooling made for java 6-8 might not work if the module-info.class exists (and it is anyway a complicated process to compile that only with 11). Additionally all dependencies must also satisfy full JPMS support.

Java 6 support cannot be dropped yet (not at least for 1.4.0 / basic UA 1.04 support) due to the additional platforms mentioned above and I would prefer to have only a single artifact output. However this can be reconsidered depending on the adoption of 11, tooling support updates, and actual need in the future (at least the #157 and #164, possibly others needs to be fixed first), but would probably need to be a separate artifact given that earlier toolings might be incompatible with module-info.class. Additionally needs investigation on how to define optional dependencies with the module system.

[tomprodehl]

I use this within a JDK 11 based product, but as far as requirements for JPMS artifacts, no, I only have a preference. A single jar artifact to support the varied platforms and JDK 11 I can see would be problematic. I may fork and mod and do this on my own. I'll offer what I do back to you if I do. Truthfully JDK 11 and JPMS is likely to be a separate branch until there is greater need and convergence. If that even happens. Mostly, I wanted to document the eventual need for JDK 11 and JPMS support with you. How this request plays out should be interesting. Thanks for your email.

[bjakke]

Adding a note here based on #181. Latest releases of https libs (4.x, that work on java 6+) + bouncycastle have automatic module names in their manifests. Spongycastle does not, but I'm not sure how much that does matter (as it is in practice only used in android). Slf4j did not have it (1.7.x), but it's 1.8.0 beta2 jar has a true module-info.class, which none of the other dependencies had.

I'll see if an automatic module name entry to the manifest could be added for 1.4.0 release, given that #164 is now done and because the latest dependencies seem to contain them anyway.

[bjakke]

The above commit now adds "org.opcfoundation.ua.stack" as the Automatic-Module-Name. I think that is what can be done for the context of 1.4.0.

I experimented with https://github.com/moditect/moditect maven plugin which allows creating and injecting the module-info to an existing jar. However I run into issues with the http libs having incompatible automatic name (the issue itself is fixed, but not released, apache/httpcomponents-core@78781ca). That is something that can be looked in the future, or used by users directly if module-info is absolutely required.