Module Layers and platform architectures

[David Lloyd]

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 <tjwats at 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.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
>> >
>>
>>

-- 
- DML • he/him
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jigsaw-dev/attachments/20241219/91177420/attachment.htm>