Alan, thank you very much for your explanations.
I created an issue https://bugs.openjdk.org/browse/JDK-8324272
So, everyone who is interested in this topic can track it.
Best regards, Pavel
On 1/19/24 4:30 PM, Alan Bateman wrote:
On 18/01/2024 13:49, PavelTurk wrote:
:
Do I understand it correctly that it is ABSOLUTELY, ABSOLUTELY impossible to do
find a solution for this problem?
I mean that all today's knowledge in software development are still not enough
to find a way
a) to provide integrity of the platform and b) to load standard (JRE/JDK)
modules in child layers?
I didn't say it was impossible, instead I listed down some of the challenges
with finding a workable solution to this type of use case. The science isn't
too difficult, it's mostly about slicing a module graph and reifying the slices
as a stack of ModuleLayers so that the ModuleLayer.Controller handed out to the
container is for a ModueLayer that doesn't include the modules mapped to the
boot or platform class loaders. The harder part is coming up with an API that
looks like it has always been there.
For now, deploying the container with --add-modules ALL-DEFAULT is not
terrible. It ensures that all modules in the run-time image that export an API
are in the boot layer so there shouldn't be any issues with modules in child
layers requiring modules that the container doesn't transitively require.
-Alan
