Module Layers and platform architectures

[Thomas Watson]

If I read the design principle correctly it works for the JDK because the
JDK produces, controls and builds all the modules it includes in the JDK
itself.  For modules running on top of the boot layer we don't have full
control over what the modules do with their targeted or qualified exports.
To do that we would have to repackage the java classes from the third-party
modules and generate the proper moule-info classes so we can hide the
internal detail packages with qualified exports.

It would be nice to be able to use the "off the shelf" modules produced by
a project that defines its own APIs without having to repackage them to
apply qualified exports.  Qualified exports are also brittle to maintain
because we have to go rebuild the exporting module every time a new module
comes along that depends on the qualified export.  This causes modules to
inch closer to becoming a monolith where all modules in the monolith must
be rebuilt in order to bring in a new module to the system.

It has been a while since I looked at qualified exports, perhaps there is
some way to qualify exports to indicate any module within the layer the
exporting module is in can access?  But even that concept is doubtful to
get widespread adoption from third-party libraries when they are defining
their APIs and want to allow the most flexibility in thier use.

Tom


On Fri, Dec 20, 2024 at 2:23 AM Alan Bateman <alan.bateman at oracle.com>
wrote:

> On 19/12/2024 16:26, Thomas Watson wrote:
> > :
> >
> > 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).
> >
> The Design principles in JEP 200 [1] for the standard and JDK modules
> may be useful in your design discussions.
>
> -Alan
>
> [1] https://openjdk.org/jeps/200#Design-principles
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jigsaw-dev/attachments/20241220/6a6803e9/attachment.htm>