RFR: 8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets

[Dan Heidinga]

On Mon, 20 Oct 2025 16:51:35 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> There may be a similar issue with `ObjectInputStream` as well as I think this forces the class to be AOTInitialized.
>> 
>>         SharedSecrets.setJavaObjectInputStreamAccess(ObjectInputStream::checkArray);
>>         SharedSecrets.setJavaObjectInputStreamReadString(ObjectInputStream::readString);
>
> These two accessors are currently not used in the AOT assembly phase. Maybe we can add an assert that the corresponding fields are null, and abort the AOT assembly otherwise?

Is there a particular subset of the SharedSecrets accessors that we want to allow to be set during the assembly phase?

Is there a way we can mark the fields in SharedSecrets as allowed to be assembly initialized vs those that must be null?

The unfortunate thing is that if these fields didn't use Lambdas, they would also be fine to assembly-time initialize as it's the side-effect of the lambda forcing init that's the problem

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27880#discussion_r2445689913