On Fri, 28 Nov 2025 13:35:51 GMT, Jaikiran Pai <[email protected]> wrote:

>> Hello Chen, should this annotation also mention what happens if a class 
>> annotated with `@TrustFinalFields` has any of its `final` fields updated? 
>> For example, `@Stable` has this to say about such unexpected updates:
>> 
>> 
>> ...It is in general a bad idea to reset such
>> * variables to any other value, since compiled code might have folded
>> * an earlier stored value, and will never detect the reset value.
>> 
>> 
>> Are there any unexpected consequences of marking a class as 
>> `@TrustFinalFields` and having a `@Stable` on any of the final fields (for 
>> example an array):
>> 
>> 
>> @TrustedFinalFields
>> class JDKFooBar {
>>     private final String reallyFinal;
>> 
>>     @Stable
>>     private final int reallyFinalButAlsoStable;
>> 
>>     @Stable
>>     private final long[] finalAndStableArray;
>> 
>> }
>> 
>> Finally, would it still be recommended that a class annotated with 
>> `@TrustFinalFields` also have a final array field annoted with `@Stable` if 
>> that array field elements are initialized to a non-default value only once?
>
> One another question - if a class/interface is annotated with 
> `@TargetFinalFields`, is that annotation only applicable to that specific 
> class or would it also be applicable for any (final fields in) subclasses of 
> that class or implementations of that interface (does the VM ignore this 
> annotation on an interface, should it)?

I don't think we should mention anything about updating final fields. If you 
use this field, you intend the fields not to get subsequently updated. 
Promising the behavior in this case only introduces more trouble and is 
meaningless for this annotation's readers. For inheritance, we can add a word 
or two.

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

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

Reply via email to