On Fri, 28 Nov 2025 10:52:42 GMT, Alan Bateman <[email protected]> wrote:
>> I took this sentence from `@AOTSafeClassInitializer`. The term "privileged" >> comes from this variable in `classFileParser.cpp`: >> https://github.com/openjdk/jdk/blob/d94c52ccf2fed3fc66d25a34254c9b581c175fa1/src/hotspot/share/classfile/classFileParser.cpp#L1818-L1820 >> >> The other annotations have this note, which seems incorrect from the hotspot >> excerpt: >> >> @implNote >> This annotation only takes effect for fields of classes loaded by the boot >> loader. Annotations on fields of classes loaded outside of the boot loader >> are ignored. >> >> >> This behavior seems to be originally changed by >> 6964a690ed9a23d4c0692da2dfbced46e1436355, referring to an inaccessible issue. >> >> What should I do with this? Should I leave this as-is and create a separate >> patch to update this comment for vm.annotation annotations, or fix this >> first and have the separate patch fix other annotations later? > > For this PR then you could just change the last sentence to say that the > annotation is only effective for classes defined by the boot class loader or > platform class loader. A follow-up PR could propose changes to the other > annotation descriptions. > > As regards background then one of the significant changes in JDK 9 was that > java.* modules could be mapped to the platform class loader without give them > "all permission" in the security manager execution mode. If you see JBS > issues or comments speaking of "de-privileging" then it's likely related to > changes that "moved" modules that were originally mapped to the boot class > loader to the platform class loader. Now that the security manager execution > mode is gone then we don't have to deal with all these issues now. 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? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2571701254
