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
