On Sat, 29 Nov 2025 07:10:20 GMT, Jaikiran Pai <[email protected]> wrote:
>> 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. > > Hello Chen, > >> because otherwise people can just blanket-approve java.util classes for >> trusting and break those applications. > > This is one of the reasons why I asked some of the questions that I did. We > have seen several PRs in the recent past where `@Stable` annotation has been > introduced in the core classes of Java SE because it aids constant folding > optimizations. Most of those changes have been backed merely by JMH > benchmarks. It won't be a surprise if we start seeing another round of PRs > where the usage of this new `@TrustFinalFields` gets proposed to some of > these classes in the JDK because it shows an improvement in some micro > benchmark. It also won't be a surprise if those PRs too won't have associated > regression tests. Furthermore, unlike `@Stable` which gets applied directly > on the field(s) of interest, this new annotation will be applied a bit "far > away" from such fields. So it will need additional review cycles to > understand if this usage can impact the code functionally in any manner. > Specifying the semantics of this annotation in various usage scenarios, in > its javadoc, will aid in reviewing such changes in future, instead of having to regularly look into the JVM code to understand how this annotation behaves. > > Classes in `java.util` aren't special in any way. So if applications are > changing the values of final fields of some of those classes, then the same > would be done for other packages of Java SE APIs too. If, like you note, > applying `@TrustFinalFields` on such classes is going to break applications, > then it will be useful to specify what kind of breakages those will be (in a > similar manner to what the `@Stable` annotation's javadoc does). > > Very specifically, I think adding a few sentences clarifying the following > scenarios in this annotation's javadoc will be useful: > > - Will this annotation be honoured only on the specific class that it is > applied to? Or will it be taken into consideration for final fields in > subclasses too? > - If this annotation gets applied on a class and if that class has some final > fields which are already marked `@Stable`, what kind of implications will > that have, if any? > - If this annotation is marked on a class which has a `final` array field > (for example `final long[] ids`), is it useful to continue placing a > `@Stable` annotation on such array fields if the elements of those arrays are > going to be initialized to a non-default value just once? > - If after all the precautions are taken, if the final field of a class... 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. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2573355600
