On Mon, 20 Oct 2025 17:40:20 GMT, Dan Heidinga <[email protected]> wrote:

>> 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

I looked at all the calls of the pattern `SharedSecrets.set.*::`


java/io/ObjectInputFilter.java: 
SharedSecrets.setJavaObjectInputFilterAccess(Config::createFilter2);
java/io/ObjectInputStream.java: 
SharedSecrets.setJavaObjectInputStreamAccess(ObjectInputStream::checkArray);
java/io/ObjectInputStream.java: 
SharedSecrets.setJavaObjectInputStreamReadString(ObjectInputStream::readString);
javax/crypto/SealedObject.java: 
SharedSecrets.setJavaxCryptoSealedObjectAccess(SealedObject::getExtObjectInputStream);


These calls are all done inside a `<clinit>`. In the four cases, only the first 
class (`java.io.ObjectInputFilter.Config`) has environment-dependent code 
inside its `<clinit>`.

Maybe we should mark the `java.io.ObjectInputFilter.Config` class with a new 
annotation `AOTUnsafeClassInitializer` (the opposite of the existing 
`AOTSafeClassInitializer`). If this class is initialized in the assembly phase, 
the VM will exit.

I think we can leave the other 3 cases alone.

An alternative is to rewrite the first case from:


SharedSecrets.setJavaObjectInputFilterAccess(Config::createFilter2);


to


SharedSecrets.setJavaObjectInputFilterAccess(new JavaObjectInputFilterAccess() {
    ObjectInputFilter createFilter2(String pattern) {
        return Config.createFilter2(pattern);
    }
});

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

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

Reply via email to