RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final [v2]

Volkan Yazici vyazici at openjdk.org
Tue Sep 30 07:31:44 UTC 2025


On Tue, 23 Sep 2025 18:03:54 GMT, Alan Bateman <alanb 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
>
> Alan Bateman has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Review feedback
>  - Change ciField::initialize_from to use is_mutable_static_final, suggested by Vladimir Ivanov

test/hotspot/jtreg/runtime/jni/mutateFinals/MutateFinalsTest.java line 109:

> 107:         String instanceMethod = list1.get(rand.nextInt(list1.size()));
> 108:         String staticMethod = list2.get(rand.nextInt(list2.size()));
> 109:         return Stream.of(instanceMethod, staticMethod);

* What is the rationale for choosing a random `pairOf(instanceMutator, classMutator)`?
* Does "instance mutator gets followed by a class mutator" have any particular importance for the tests they are used?

I was looking at this argument supplier and thinking of `Collections.shuffle()` over a list containing all method names, preferably, multiple times.

test/hotspot/jtreg/runtime/jni/mutateFinals/MutateFinalsTest.java line 142:

> 140:     private OutputAnalyzer test(String methodName, String... vmopts) throws Exception {
> 141:         Stream<String> s1 = Stream.of(
> 142:                 "-Djava.library.path=" + javaLibraryPath,

`javaLibraryPath` is only used here. You can consider inlining `System::getProperty` here and saving yourself from lines 51..56.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2382369054
PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2382360896


More information about the core-libs-dev mailing list