<div dir="auto">That does sound interesting.  Not knowing the details though I am unsure if it helps solve the problem.<div dir="auto"><br></div><div dir="auto">It sounds like a step after first enhancing the runtime layer configuration to handle adding application layers as children to the platform layer while hiding the platform implementation detail modules from the application modules.</div><div dir="auto"><br></div><div dir="auto">Once that is possible then it would be nice to be able to persist (build) that into a jlink image that reifies into the different layers.</div><div dir="auto"><br></div><div dir="auto">Tom</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, Dec 19, 2024, 1:22 PM Ron Pressler <<a href="mailto:ron.pressler@oracle.com">ron.pressler@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Sounds like a jlink image that resolves into multiple layers would give you what you want. It’s my understanding that this was relegated to “future work”, but there hsan’t been enough interest to work on that.<br>
<br>
— Ron<br>
<br>
> On 19 Dec 2024, at 16:26, Thomas Watson <<a href="mailto:tjwats@gmail.com" target="_blank" rel="noreferrer">tjwats@gmail.com</a>> wrote:<br>
> <br>
> During the service loading discussion I was reminded of a problem I encountered while considering Java Modules (before even Java 9 came out) when I was investigating how to integrate OSGi with Java Modules.<br>
> <br>
> One complication I had when considering Java modules for our modular runtime (Open Liberty) was that we have many modules that contribute to our platform implementation (i.e. Jakarta EE).  Some modules provide API that is intended for applications to use.  Some modules provide packages that other modules in the platform need as an implementation detail for the platform.  For example, maybe some third-party module for the persistence implementation (e.g. EclipseLink).<br>
> <br>
> What we do today is expose the APIs (i.e. packages in the jakarta namespace) to applications while hiding the exported packages from third-party modules which provide implementation details. What I originally wanted to do was to be able to jlink all our modules for a specific feature set which would then be reified into a single module layer at runtime.  Then have the platform create new layers for applications to live in.  But I saw no way to keep our implementation detail modules hidden from the new layers created by the application.  Of course there are qualified or targeted exports where a module can export a package to a specific list of modules, but third-party modules from open source projects are not going to use qualified exports for their APIs that we use as internal implementation details.<br>
> <br>
> We could provide a ModuleFinder that would find modules in the application layer first, but then we always have to delegate to the configuration of the parent layer if the module is not found and we have no control of the final Configuration implementation.  This means application layers can bind to our implementation details when we don't want to allow that.  It did not seem feasible to break up the API modules from the implementation detail modules such that the "API" layer would be the parent configuration for application layers and somehow hide the implementation layer as a sibling of or child to the "API" layer.<br>
> <br>
> To make that feasible it would have been nice to have more control over what modules a child layer can bind to from its parent configurations. If we had something like this we may have more strongly considered how to use and support modules at runtime for applications on our platform.<br>
> <br>
> I have to admit that since that time we have not seen any demand from our customers to support modules at runtime for their applications. Even if you provided this today, it is unlikely I could justify my time to further investigate using the new functionality.<br>
> <br>
> Tom<br>
> <br>
<br>
</blockquote></div>