> On 14 Jan 2025, at 13:26, Code Ranger <coderanger2...@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
