<div dir="ltr">If I read the design principle correctly it works for the JDK because the JDK produces, controls and builds all the modules it includes in the JDK itself.  For modules running on top of the boot layer we don't have full control over what the modules do with their targeted or qualified exports.  To do that we would have to repackage the java classes from the third-party modules and generate the proper moule-info classes so we can hide the internal detail packages with qualified exports.<div><br></div><div>It would be nice to be able to use the "off the shelf" modules produced by a project that defines its own APIs without having to repackage them to apply qualified exports.  Qualified exports are also brittle to maintain because we have to go rebuild the exporting module every time a new module comes along that depends on the qualified export.  This causes modules to inch closer to becoming a monolith where all modules in the monolith must be rebuilt in order to bring in a new module to the system.</div><div><br></div><div>It has been a while since I looked at qualified exports, perhaps there is some way to qualify exports to indicate any module within the layer the exporting module is in can access?  But even that concept is doubtful to get widespread adoption from third-party libraries when they are defining their APIs and want to allow the most flexibility in thier use.</div><div><br></div><div>Tom</div><div><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, Dec 20, 2024 at 2:23 AM Alan Bateman <<a href="mailto:alan.bateman@oracle.com">alan.bateman@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 19/12/2024 16:26, Thomas Watson wrote:<br>
> :<br>
><br>
> One complication I had when considering Java modules for our modular <br>
> runtime (Open Liberty) was that we have many modules that contribute <br>
> to our platform implementation (i.e. Jakarta EE).  Some modules <br>
> provide API that is intended for applications to use.  Some modules <br>
> provide packages that other modules in the platform need as an <br>
> implementation detail for the platform.  For example, maybe some <br>
> third-party module for the persistence implementation (e.g. EclipseLink).<br>
><br>
The Design principles in JEP 200 [1] for the standard and JDK modules <br>
may be useful in your design discussions.<br>
<br>
-Alan<br>
<br>
[1] <a href="https://openjdk.org/jeps/200#Design-principles" rel="noreferrer" target="_blank">https://openjdk.org/jeps/200#Design-principles</a><br>
</blockquote></div>