jlink images and module layers

[Alan Bateman]

On 10/02/2021 21:44, Gunnar Morling wrote:
> 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.
It would need a lot of consideration and exploration before going there. 
One reason for having different versions of a module in the run-time 
image might be to support different initial modules, say a run-time 
image containing two distinct applications or tools. Both would run with 
in flat name space but for whatever reason can't use the same version of 
some module. At the other extreme might be launching an application that 
is magically started with several layers and different versions of 
modules in each layer. Somewhere in the middle is a container in the 
boot layer and at run-time it uses the APIs to create module layers. The 
set of observable modules that it uses when creating the configurations 
for these modules layer is some subset of the modules in the run-time 
image that include modules that weren't observable at startup when 
creating the boot layer.



>
> 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://urldefense.com/v3/__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__;Iw!!GqivPVa7Brio!L0YyyA2bQu9Mr2QdbMC3mK-U7Vkt8WmI3LIlw_FmwS58Iqo42j9JN77ETD7lxI-Q-Q$
>
> 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.
The load(ModuleLayer, service) is specified to load service providers in 
the given layer and its ancestors. That is consistent with the load 
method that takes a ClassLoader as that has always been specified to use 
the class loaders that are reachable via parent delegation.

The stream() method might be useful for the example as you could use a 
filter to selects providers in the desired layer.

What parent class loader do you specify to defineModulesXXXX when you 
are creating the module layers? I'm asking because the traditional 
ServiceLoader.load will locate providers in named modules when the class 
loader specified to the method has modules in a module layer. This goes 
for class loaders that are reachable via parent delegation too. When 
Layrry creates a layer with defineModulesXXXX then it must specify the 
parent class loader for the resulting class loaders. If you choose one 
of the class loaders from the layer parent (any of them will do) then it 
might get more of the traditional usages of ServiceLoader.load working.

-Alan