ModuleLayer for java.base only

[Michał Kłeczek]

> On 8 Oct 2025, at 20:54, Jaroslav Tulach <jaroslav.tulach at enso.org> wrote:
> 
> On středa 8. října 2025 20:06:13, středoevropský letní čas, Michał Kłeczek 
> wrote:
>>> On 8 Oct 2025, at 19:39, Alan Bateman <alan.bateman at oracle.com> wrote:
>>> 
>>> On 08/10/2025 06:19, Jaroslav Tulach wrote:
>>>> How that is supposed to work? How do I create a `ModuleLayer` with just
>>>> `java.base` and control what the Enso library JARs can access? Can I
>>>> control that regardless of how the JVM was initialized? There must a a
>>>> way, right? Or am I asking for too much encapsulation?
>>> 
>>> I think what you are looking for is to create the Configuration for a
>>> child layer in a way that "hides" all but java.base from the modules in
>>> the parent configuration. There isn't a way to do this as resolution
>>> time. That is, if the configuration for the parent/boot has java.base,
>>> enso, and apache.foo (used by enso) then there is no way to have
>>> resolution fail if a user module requires enso or requires apache.foo.
>>> 
>>> Who creates the configuration for the child layer? Can it process the
>>> Configuration and fail if any module in the configurations reads a module
>>> other than java.base?
>> Another approach would be to have only a closed “bootstrap" module in module
>> path.
> 
> Thanks for your reply, Michał.
> 
> This solution might work for Enso application and yes, I am considering to go 
> this route. E.g. to alter boootstrap path to
> 
> 
>> ... provide main class, initialize a module layer with all Enzo
>> modules and their dependencies, and pass execution to it.
> 
> However, Enso isn't just an application, but a language component embeddable 
> into other Java applications. In such situation Enso isn't in control of the 
> JVM bootstrap and cannot perform this kind of equilibristic.

If you make the embedding application link to only the Enso bootstrap module would solve the issue, wouldn’t it?

Encapsulating internals of Enso can be achieved by simply putting it in a single module and not exporting anything.
(Or you can use “export … to …” if you really need multi-module Enso)

So I understand your real goal is to insulate users of Enso from versions of its dependencies.
In case of embedding Enso it is then responsibility of the embedding application - it has to make sure its own dependencies do not interfere with modules it loads.

—
Michal