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

Ioi Lam iklam at openjdk.org
Mon Oct 20 16:54:03 UTC 2025


On Mon, 20 Oct 2025 13:53:52 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/access/SharedSecrets.java line 65:
>> 
>>> 63: 
>>> 64: // Static fields in this class are stateless, so the values initialized in the
>>> 65: // AOT assembly phase can be safely cached.
>> 
>> Looking through the implementations of the Access classes, and I have concerns about:
>> `setJavaObjectInputFilterAccess` as it is implemented using a lambda:
>> 
>> SharedSecrets.setJavaObjectInputFilterAccess(Config::createFilter2);
>> 
>> Correct me if I'm wrong, but I believe that will cause the `Config` class to be AOTInitialized as well?
>> 
>> `Config` has a couple of system properties (-Djdk.serialFilter= for one) that we may not want to initialize during the assembly phase.
>
> 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?

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

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


More information about the core-libs-dev mailing list