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

[Chen Liang]

On Mon, 22 Sep 2025 17:33:56 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/reflect/Field.java line 1439:
>> 
>>> 1437:         } else {
>>> 1438:             // no java caller, only allowed if field is public in exported package
>>> 1439:             if (!Reflection.verifyPublicMemberAccess(clazz, modifiers)) {
>> 
>> Is this sufficient? I know core libraries has APIs as public non-static final fields, like java.lang.constant.DirectMethodHandleDesc$Kind.refKind. Don't think they should be allowed to be modified by native code, for example.
>
> If a JNI attached thread does an upcall to Field.set with no Java frames on the stack, then it is can mutate a public final field in a public class in an exported package when "illegal final field mutation" is allowed. If denied then IAE will be thrown.

This is a good transition measure. I assume that we can allow JIT compilers to constant fold when both illegal final field mutations are disabled, and no module is opening the member's package and enabling field mutation at the same time. (We might add such a check for "safe for constant folding" in the compiler interface as later work)

>> test/langtools/jdk/jshell/CompletionSuggestionTest.java line 35:
>> 
>>> 33:  * @build toolbox.ToolBox toolbox.JarTask toolbox.JavacTask
>>> 34:  * @build KullaTesting TestingInputStream Compiler
>>> 35:  * @run junit/othervm/timeout=480 CompletionSuggestionTest
>> 
>> Why does this need an update?
>
> I mentioned this in the PR description because it is necessary to change a small number of tests ro run in /othervm mode. This is because jtreg reflectively opening a package isn't sufficient, it has to run the test with `--add-opens`.

Do you think we should update jtreg to fail in the future if `@modules` is specified without othervm, like how `@enablePreview` works today?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2369641672
PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2369650042