RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting [v2]

[Alan Bateman]

On Sun, 30 Nov 2025 07:51:51 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> If you want an essay, I have written one - I just hope whatever bikeshedding for this essay does not affect the progress of Lazy Constant's performance demands.
>
>> * If after all the precautions are taken, if the final field of a class annotated with `@TrustFinalFields` does get updated to a new value, what kind of impact would it have (stating that such behaviour is unspecified and in general is a bad idea would be enough, if that's all there is to it)
> 
> Field.set, which is probably the API that these libraries are using, already includes a warning about "unpredictable effects, including cases in which other parts of a program continue to use the original value of this field", so I think that is okay for now.

> Existing users have been hacking java.util final fields. I think leaving out the backward compatibility part causes more trouble, because otherwise people can just blanket-approve java.util classes for trusting and break those applications.

I don't think we have a lot of data on this as it doesn't lend itself to static analysis. Aside from serialization libraries, it's possible the hacking of finals is ad hoc and in random areas (someone pointed to something in Netty hacking a final field in a class in sun.nio.ch at one point). So I probably wouldn't call out java.util specifically but maybe you brought that up specifically as there are so many performance critical classes there.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2573499552