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