Module Layers and platform architectures

[Thomas Watson]

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/998975c6/attachment.htm>