I wonder: would this also allow services to be found across the layer boundaries? For example, an API from a layer that the application can see uses a service provided by an implementation in a layer that the application cannot see?
On Thu, Dec 19, 2024 at 2:46 PM Thomas Watson <tjw...@gmail.com> wrote: > That does sound interesting. Not knowing the details though I am unsure > if it helps solve the problem. > > 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. > > 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. > > Tom > > On Thu, Dec 19, 2024, 1:22 PM Ron Pressler <ron.press...@oracle.com> > wrote: > >> 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. >> >> — Ron >> >> > On 19 Dec 2024, at 16:26, Thomas Watson <tjw...@gmail.com> wrote: >> > >> > 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. >> > >> > 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). >> > >> > 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. >> > >> > 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. >> > >> > 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. >> > >> > 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. >> > >> > Tom >> > >> >> -- - DML • he/him
