<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<br>
<div class="moz-cite-prefix">On 1/14/25 14:30, Ron Pressler wrote:<span style="white-space: pre-wrap">
</span></div>
<blockquote type="cite" cite="mid:C644F77E-7757-4E7E-A489-AC0A22D4FEC0@oracle.com">
<pre class="moz-quote-pre" wrap="">
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 (<a class="moz-txt-link-freetext" href="https://openjdk.org/jeps/8305968">https://openjdk.org/jeps/8305968</a>) 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
</pre>
</blockquote>
<br>
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.<br>
<br>
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:<br>
<br>
--add-opens java.base/java.time=json //this is bad, but the JDK
supports it because it’s unavoidable.<br>
bootLayerController.addOpen(baseModule, "java.time", jsonModule)
//this is bad, the JDK will not support it because it’s bad, very
bad, unacceptably bad.<br>
<br>
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 -
<a class="moz-txt-link-freetext" href="https://stackoverflow.com/a/70878195">https://stackoverflow.com/a/70878195</a><br>
<br>
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.<br>
</body>
</html>