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.
