[External] : Re: provides and requires static ... runtime error

[Ron Pressler]

On 26 Apr 2023, at 02:51, Rob Bygrave <robin.bygrave at gmail.com<mailto:robin.bygrave at gmail.com>> wrote:

- Would this solution be intended to work for older versions of Java at runtime like Java 11? We probably can't answer this yet but open source libs tend towards supporting a minimum version based on LTS for better or worse (and will be keen to know if they can adopt this by using the latest build tooling but still support older/existing java runtimes. If so, I would think that would greatly help the adoption of the 2 modules in 1 jar solution).

The answer to that is no. If and when we support multi-module JARs, that new feature will not be backported. Libraries that wish to support old versions have always had this problem, but the solution is to pick some minimal version and employ only the features available in that version. A new feature can be used once the baseline JDK version of the library is pushed past the versions that don’t have the feature.

- For my own personal interest, what are the other motivations for supporting multiple modules in a single jar? (If these other motivations are high that improves our chances of seeing this solution happen)

The freedom to pick the desired artefact-splitting rather than have it forced by module boundaries. If a library is made up of multiple modules, all of whom are needed for the library’s functionality, it could be distributed as a single JAR.


Workarounds today

- [3] Splitting the artifact / Have a separate jar for the optional service implementation


This is what you should do today, and it isn’t a workaround but the correct way of doing things. The use of a build tool like Maven shouldn’t be a problem (and if it is, it’s something to be addressed by Maven). Maven can be configured to always add all artefacts to the module path, including the plugin. If no module declares that it `uses` the service, that module will simply not be resolved. The same considerations have always applied when the classpath is used. The only pain is that you, as the library’s author, have to build more artefacts, but since they’re handled by Maven on the user side, and because having many artefacts is already the norm, I don’t think the pain is too large.

— Ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jigsaw-dev/attachments/20230426/7b8cc670/attachment-0001.htm>