On Mon, 17 Nov 2025 10:48:38 GMT, Alan Bateman <[email protected]> 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 warning and -Xlog:jni=debug logs a >> message to help identity JNI code that mutates finals. For now, JNI code is >> allowed to set the "write-protected" fields System.in/out/err without a >> warning, 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 with a new target base due to a > merge or a rebase. The pull request now contains 63 commits: > > - Merge branch 'master' into JDK-8353835 > - Spurious italics > - More wordsmithing > - Improve IAE exception message > - Merge branch 'master' into JDK-8353835 > - Cleanup > - More cleanup of Field.set API docs, including some restructure from Alex > - Cleanup > - Merge branch 'master' into JDK-8353835 > - Update mutateFinals/modules test to exercise exports and opens cases > - ... and 53 more: https://git.openjdk.org/jdk/compare/8690d263...c3c3cfff Hi, with the upcoming changes where modifying final fields of **non-Serializable** classes will be considered illegal, are there any alternative approaches to instantiate an object without invoking its constructors while still initializing its final fields? For example, consider the following class: public final class Foo { public final long bar; private Foo() { this.bar = 1; } } In previous releases, it was possible to construct an instance like Foo { bar = 2 } with: // Obtain sun.misc.Unsafe#theUnsafe via reflection Foo foo = theUnsafe.allocateInstance(Foo.class); // Modify Foo#bar via reflection barField.set(foo, 2); However, this approach relies on modifying final fields, which is no longer allowed under the new restrictions. I’ve been looking for alternative solutions but haven’t found a viable replacement so far. The JEP mentions: > This API allows a serialization library to obtain a [method > handle](https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/invoke/MethodHandle.html) > to special code that initializes an object by assigning to its instance > fields directly, including final fields. This code, which is dynamically > generated by the JDK, gives the serialization library the same powers as the > JDK's own serialization facilities; it is not necessary to enable final field > mutation by the module of the serialization library. Am I missing something here, or is there currently no supported way to achieve this? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25115#issuecomment-4073963945
