On Sun, 30 Nov 2025 07:51:51 GMT, Alan Bateman <[email protected]> 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
