[External] : Re: How to open a package from a module in the boot layer to a module in another layer?

[Ron Pressler]

> On 14 Jan 2025, at 13:26, Code Ranger <coderanger2025 at outlook.com> wrote:
> 
> 
> On 1/14/25 14:30, Ron Pressler wrote:
>> 
>> What you’re proposing, i.e. a mechanism to grant a specific module the permission to edit the boot layer and, in particular java.base, may be workable in practice, but the problem is that it is probably a very bad idea.
>> 
>> Opening java.base is not only unrecommended but an extreme operation that could be dangerous (even result in undefined behaviour or worse) and is meant as a temporary measure until the underlying issues that require it are fixed. Needing to open or export packages in java.base signifies a problem with the program and is not a normal or healthy mode of operation. The Integrity by Default JEP (https://openjdk.org/jeps/8305968) offers recommendations for how code that, say, serializes java.base classes should work without opening java.base.
>> 
>> Remember that modules are a feature added to allow code that needs to trust certain invariants to do so, and the JDK modules, java.base in particular, need such invariants to ensure their correct operation. A plugin that requires hacking the JDK internals is a problematic plugin, and one that could risk the entire application. The user needs to be aware when such a plugin is used.
>> 
>> If you believe it's okay for the invariants of your core components possibly being compromised by plugins, that’s fine — and you can do what Alex suggested — but the JDK isn’t okay with that. If you insist on opening java.base to all code, that is an extreme, non-standard, and dangerous mode that *should* require extreme measures such as employing an agent — not a standard API.
>> 
>> — Ron
>> 
>> 
> 
> You are shifting the focus of my issue. My issue is not about opening modules in the boot layer but about doing dynamically what can currently only be done statically using the --add-* parameters.
> 
> I agree with you that adding custom directives to JDK modules is a bad idea… a very bad idea… a temporary solution… something to be avoided. Yes, I completely agree with you. But I’m talking about something else. I’m saying that since we are sometimes forced to add these directives, let’s make it possible not only during JVM startup but also at runtime. In other words, you’re saying:
> 
> --add-opens java.base/java.time=json     //this is bad, but the JDK supports it because it’s unavoidable.
> bootLayerController.addOpen(baseModule, "java.time", jsonModule)   //this is bad, the JDK will not support it because it’s bad, very bad, unacceptably bad.
> 
> But I’m saying that these two solutions are equivalent—at least they should be (I haven’t tested it). However, the second solution is more flexible, convenient, and even safer. Yes, it is safer. Please, see this SO answer that is the most upvoted - https://stackoverflow.com/a/70878195
> 
> As for the temporary nature of this solution—that’s not a problem. Access to the boot layer controller can be removed at the same time as the --add-* parameters. I think by the year 3080, this feature will no longer be relevant.


What I’m saying is that since you agree that granting some component the power to decide, at runtime, that strings are not immutable and that the number 5 may sometimes have the value of 6 (as that’s what opening java.base means) will still require some static configuration, then globally changing the semantics of Java code at runtime is already possible in this way via agents (https://docs.oracle.com/en/java/javase/23/docs/api/java.instrument/java/lang/instrument/Instrumentation.html#redefineModule(java.lang.Module,java.util.Set,java.util.Map,java.util.Map,java.util.Set,java.util.Map)). The JDK already supports this and so there’s no need for yet another mechanism.

— Ron