On Sun, 30 Nov 2025 05:19:22 GMT, Chen Liang <[email protected]> wrote:
>> 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... > > 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. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2573494589
