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

[Alex Buckley]

On 1/14/2025 9:12 AM, Code Ranger wrote:
> Why did you add --add-* parameters to JDK? Is it a problem that should 
> be solved?

The "Integrity by Default" JEP explains that there are four unsafe APIs 
-- see https://openjdk.org/jeps/8305968#Undermining-integrity.

The JEP goes on to explain that these APIs are "essential for a 
relatively small number of libraries, frameworks, and tools whose core 
functionality cannot be implemented any other way" -- see 
https://openjdk.org/jeps/8305968#Restrictions-on-standard-unsafe-APIs.

The JEP then ties the --add-* and other command line options directly to 
the four unsafe APIs.

The purpose of these command line options is to enumerate which specific 
code needs to use unsafe APIs. This provides an audit function if use of 
unsafe APIs leads to problems for users. The best number of these 
command line options is zero, which means nothing in the stack is using 
unsafe APIs and the stack can be expected to run smoothly on newer JDKs.

You have proposed a command line option that gives superpowers to a 
specific module, so it can obtain and manipulate the boot layer's 
controller. This option will not be added, for two reasons:

   1. It's not related to use of the unsafe APIs. It just happens to 
feel similar. Outside the domain of unsafe APIs (and setting aside 
"meta" topics like preview APIs), we don't offer command line options 
that let some code do things which are unavailable or disallowed in the 
Java Platform API for other code.

   2. It's specific about which module would have superpowers, but 
there's no auditability for users. The module's code is a black box: it 
could export different packages to different clients at different times. 
I expect you view this flexibility as a feature, but we view it as a 
problem: there is nothing to stop the module from opening JDK internals 
so that other code (perhaps in a different module) can use 
setAccessible, an unsafe API, to access them _without any command line 
acknowledgement that this is occurring_. This open-ended, back-door 
access to JDK internals flies directly in the face of our 
integrity-by-default policy.

The recommended solution for you is to load the bulk of your application 
and its plugins in their own layers, outside the boot layer. You will 
then have supreme control over the accessibility of your own code and 
any third party code that you load.

Access to JDK internals -- whether unsupported classes in jdk.internal.* 
packages or undocumented members of the java.time package -- is 
something for users to grant to you, not something for you to take.

Alex