On 08/10/2025 20:11, Jaroslav Tulach wrote:
From a rationalistic perspective, I am looking for something very different:
I'd like to start from scratch - e.g. `ModuleLayer.empty()` and built
something on top of it myself. E.g. create a layer with
`ModuleFinder.ofSystem()` where I include only some JDK modules - like
`java.base` (but certainly not `org.graalvm.collections`).
Why that isn't possible?
Is there a technical problem in creating multiple layers that would all
contain `java.base`?
Or I am just first one who's asking for a feature like this?
There can only be one instance of java.base in the runtime, in the same
way that there is one java.lang.Object class. You are right that
Configuration.empty() and ModuleLayer.empty() are not interesting
outside of creating the boot layer or tests.
It is possible to start with `--limit-modules java.base` so that the
boot layer only contains java.base but you cannot stack module layers
that contain the platform modules. There are technical and non-technical
issues that prevent the java.* name space being used by custom class
loaders, and it's not possible to give away control of the boot or
platform class loaders without introducing major security + integrity
risk. The original requirements for Project Jigsaw did envisage allowing
some means to augment the set of platform modules at runtime but it
hasn't been a priority to work on. The mundane cases that have been
important is the dynamic loading of the java.instrument and
java.management modules, something that is done in a very limited and
controlled manner in response to commands that load tool agents.
As regards your desire to hide Enso, and the modules that it uses, from
applications then it is something that has come once or twice, usually
in the context of some container/application server that wants to hide
its dependences from applications that it launches. The module system
does not provide this type of isolation.
-Alan
