<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <div class="moz-cite-prefix">On 08/10/2025 20:11, Jaroslav Tulach
      wrote:<span style="white-space: pre-wrap">
</span></div>
    <blockquote type="cite" cite="mid:3165226.BEx9A2HvPv@lintel">
      <pre wrap="" class="moz-quote-pre">
>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?</pre>
    </blockquote>
    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.<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    -Alan<br>
  </body>
</html>