RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final
Alan Bateman
alanb at openjdk.org
Tue Sep 23 15:53:42 UTC 2025
On Mon, 15 Sep 2025 13:53:28 GMT, Chen Liang <liach at openjdk.org> wrote:
>> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500).
>>
>> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP.
>>
>> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a fatal error when a mutating a final field with JNI, and -Xlog:jni=debug can help identity when JNI code mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX).
>>
>> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package.
>>
>> Testing: tier1-6
>
> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 3449:
>
>> 3447: }
>> 3448: // check if write access to final field allowed
>> 3449: if (!field.isStatic() && isAccessible && allowedModes != TRUSTED) {
>
> I don't think we need this allowedModes special permission - I see no scenario in which the core libraries implementation needs to perform such a reflective operation.
Thanks for pointing that out. It used to be required due to re-implementation of core reflection but you are right that it shouldn't be there now.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2372776072
More information about the core-libs-dev
mailing list