jlink images and module layers

[Gunnar Morling]

Hi Alan,

Thanks for your thoughtful reply. The use case I'd see for layers
within jlink images is isolation of different (transitive) dependency
versions within an application. While this isn't present (and I
understand it'd add a fair share of complexity), we can work around
this by putting the modules of different layers into a separate
directory and use this as source for the layers running on top of the
JDK modules from the image. We might envision some tooling support for
creating such "extended" jlink image.

Btw. when exploring dynamic plug-in layers and their interaction with
services, we noticed that you'll also get services provided by parent
layers. This leads to code patterns like shown here:

    https://github.com/moditect/layrry-examples/blob/master/modular-tiles/core/modular-tiles-core/src/main/java/org/kordamp/tiles/core/TilePluginLifecycleListener.java#L41-L43

I.e. you need to filter out all those service implementations from
parent layers. It would be nice if there was a flavour of load()
(perhaps just a boolean flag "includeParentLayers"), which would make
this a bit simpler. Also, IIUC, the code using the service loader
needs to have awareness of the fact that it runs within layers, as the
traditional load() methods wouldn't find any implementations from
parent layers, which might present a migration obstacle when moving
existing libraries to layered architectures.

Best,

--Gunnar


Am Sa., 6. Feb. 2021 um 17:56 Uhr schrieb Alan Bateman
<Alan.Bateman at oracle.com>:
>
> On 05/02/2021 15:39, Gunnar Morling wrote:
> > Hi all,
> >
> > While working on Layrry [1] [2] [3], a launcher and runtime for
> > layered Java applications, I've come to wonder whether there's a way
> > for sourcing multiple module layers from a custom runtime image
> > created via jlink?
> >
> > I couldn't find a way so far, as a) it seems not possible to add
> > multiple versions of a module to a runtime image (one of the use cases
> > for layered applications), and b) it's not clear how the module finder
> > API would address modules in an image. If this is not supported atm.,
> > are there any plans to do so?
> >
> > To give some context on Layrry, it's an exploration for providing a
> > framework that allows the creation of modularized applications based
> > on the module system and its notion of layers, addressing the
> > multi-version issue of (transitive) dependences, provisioning modules
> > based on their Maven coordinates, supporting the dynamic
> > addition/removal of layers at runtime ("plug-ins"), and more.
> >
> No, there isn't any support for this.
>
> As things stand, the universe of observable modules at startup includes
> all modules in the run-time image. If a run-time image were to include
> modules only intended for module layers created at run-time then there
> would need to be configuration or something to support the partitioning,
> also maybe APIs to expose enough at run-time to reconstitute the
> configuration. There would be restrictions on the content of these
> modules, e.g. modules intended only for child layers couldn't contribute
> command-line launchers for the bin directory. The container format used
> for classes and resources would need to be rev'ed to support more
> complex addressing (this is something we explored a bit in JDK 9 but
> didn't go too far), or the run-time image structure would need to be
> updated to support directories of observable modules for each
> configuration. A lot of complexity would be heaped on jlink as it would
> have to create the configuration for each of the layers at link time,
> maybe even a training run to map the modules to class loaders to
> identity consistency issues at link-time. Overall I think it would add a
> lot of complexity in many areas.
>
> Module layers are great for containers that launch applications that use
> different versions of components, it's also great for plugins and
> dynamic behavior (the "Finding Plug-In Implementations ..." section in
> your blog is good). I'm less sure about trying to bring it to the link
> phase where it's about static configuration and link-time optimizations.
>
> -Alan
>