RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final

David Holmes dholmes at openjdk.org
Tue Sep 23 05:46:40 UTC 2025


On Thu, 8 May 2025 11:22:30 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

Hotspot changes are okay in principle but the JNI checks could be more streamlined to avoid duplication. There is also a more general cleanup of `Klass*` versus `InstanceKlass*` that simplifies things somewhat, though much of that would be external to this PR.

src/hotspot/share/prims/jni.cpp line 1870:

> 1868: }
> 1869: 
> 1870: static void log_debug_if_final_static_field(JavaThread* thread, const char* func_name, Klass* klass, int offset) {

If `thread` is required to be the current thread, please call it `current`.

src/hotspot/share/prims/jni.cpp line 1873:

> 1871:   if (log_is_enabled(Debug, jni)) {
> 1872:     fieldDescriptor fd;
> 1873:     bool found = InstanceKlass::cast(klass)->find_field_from_offset(offset, true, &fd);

If you are assuming/expecting an `InstanceKlass` then that should be the type of the parameter. (The existing code needs a cleanup in this area too but that is outside the scope of this PR.)

src/hotspot/share/prims/jniCheck.cpp line 1224:

> 1222: WRAPPER_GetField(jdouble,  Double,  T_DOUBLE)
> 1223: 
> 1224: static void checkCanSetInstanceField(JavaThread* thr, jfieldID fid, jobject obj) {

There is a lot of duplication here with logic already performed in `checkInstanceFieldID` - can you not just pass an extra argument `is_set` to that and include the new checks there? And similarly for the static case.

src/hotspot/share/runtime/fieldDescriptor.cpp line 53:

> 51:   // write protected fields (JLS 17.5.4)
> 52:   if (is_final() && is_static() && ik == vmClasses::System_klass() &&
> 53:       (offset() == java_lang_System::in_offset() || offset() == java_lang_System::out_offset() || offset() == java_lang_System::err_offset())) {

I thought the ability to mutate these fields was restricted to the native implementations of `setIn` et al. and was not allowed via regular reflection? Otherwise how can these fields be considered as "trusted finals"??

test/jdk/java/lang/reflect/Field/mutateFinals/jni/JNIAttachMutatorTest.java line 29:

> 27:  * @summary Test native thread attaching to the VM with JNI AttachCurrentThread and directly
> 28:  *    invoking Field.set to set a final field
> 29:  * @requires (os.family == "linux" | os.family == "mac")

This test should work for any non-Windows platform using pthreads.

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

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25115#pullrequestreview-3256235026
PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2371150541
PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2371151309
PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2371182004
PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2371207094
PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2371211878


More information about the core-libs-dev mailing list