On Fri, 28 Nov 2025 15:06:50 GMT, Chen Liang <[email protected]> wrote:
>> src/java.base/share/classes/jdk/internal/vm/annotation/TrustFinalFields.java >> line 49: >> >>> 47: /// As a result, this should be used on classes where package-wide >>> trusting is >>> 48: /// not possible due to backward compatibility concerns, such as for >>> `java.util` >>> 49: /// classes. >> >> Should this sentence be reworded? It's not clear what the backward >> compatible concerns (for `java.util` package) are. I think it might be >> better to leave out any backward compatibility part when explaining which >> classes to use this annotation on. > > 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 su ch 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 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) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2572850670
