<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
<br class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On 26 Apr 2023, at 02:51, Rob Bygrave <<a href="mailto:robin.bygrave@gmail.com" class="">robin.bygrave@gmail.com</a>> wrote:</div>
<div class="">
<div dir="ltr" class=""><br class="">
<div class="">- 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).</div>
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>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.</div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" class="">
<div class="">- 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)</div>
</div>
</div>
</blockquote>
<div><br class="">
</div>
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.</div>
<div><br class="">
<blockquote type="cite" class="">
<div dir="ltr" class="">
<div class=""><br class="">
</div>
<div class=""><b class="">Workarounds today</b></div>
<div class=""><br class="">
</div>
<div class="">- [3] Splitting the artifact / Have a separate jar for the optional service implementation</div>
<div class=""><br class="">
</div>
</div>
</blockquote>
<br class="">
</div>
<div>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.</div>
<div><br class="">
</div>
<div>— Ron</div>
</body>
</html>