On Mon, 20 Oct 2025 13:51:18 GMT, Dan Heidinga <[email protected]> wrote:
>> By annotating `SharedSecrets` as `@AOTSafeClassInitializer`, we can avoid
>> using the `@AOTRuntimeSetup` annotations in a few JDK core classes. This
>> simplifies the implementation. It also brings us closer to the goal of
>> making the AOT cache as a true snapshot of the JVM state that just needs to
>> be resumed in the production run.
>
> 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);
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/27880#discussion_r2445095385
