[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:06, Andrew Dinn <adinn at redhat.com> wrote:
> 
> 
> I certainly think Java devs should and mostly do agree that opening java.base to all code is a non-standard and risky mode in which to operate the JVM (n.b. I switched out 'dangerous' and 'extreme' as I'm not quite sure what they add to your pejorative assessment beyond jeremiad-redolent rhetoric). However, you also seem to be saying that employing an agent is an extreme measure. How so?

I meant extreme in its power. Seeing an agent declared on the command line is good indication that “normal rules may not apply”. Using an agent is, of course, a valid thing to do in general.

> 
> I have a corollary question: are you implying that using an agent to expose java.base code selectively to targeted library, framework or, even, application code is always inherently risky (dangerous or extreme, even)?

Opening java.base in any way is always inherently risky. It means that whether *any* platform invariants hold is now in the hands of some non-JDK code. For example, it means that no string in the program can be trusted to be immutable, and some day it may mean that non-JDK code would decide whether any array’s bounds-checking is performed .

> I  ask because agents *are* provided with a API that explicitly enables them to do this and you appear to be suggesting that this was/is a mistake (n.b. that API was added because I demonstrated that, absent such an API and given sufficient bytecode weaving ingenuity, an agent can easily achieve the same outcome as if it were to use the API, only probably with more risk of error).

I don’t think it’s a mistake because sometimes it is useful to change the laws of the universe. The use of an agent signifies that the laws of the universe are now in the hands of the agent rather than the JDK, and as long as that’s clear, I think it’s fine.

The idea of integrity by default is that the *application* (though not libraries placed on the module/class path) gets to decide what the rules are, because that’s always the case. The application controls the launcher and runtime anyway; it’s free to select a modified runtime, or even one that isn’t Java at all. Because only the application can load an agent (at least without a warning) it’s fine.

What Code Ranger suggested — adding yet *another* mechanism that hands the keys to the kingdom to some code is, I think, a bad idea because we already have agents, and their potential impact is already known.

— Ron