RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting

[Chen Liang]

On Fri, 28 Nov 2025 13:35:51 GMT, Jaikiran Pai <jpai at openjdk.org> 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