Module Layers and platform architectures

[Thomas Watson]

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.pressler at 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 <tjwats at 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
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jigsaw-dev/attachments/20241219/bbc0666a/attachment-0001.htm>