kryo icon indicating copy to clipboard operation
kryo copied to clipboard

Deserialization fails with Java17.

Open vjhpe opened this issue 3 years ago • 1 comments

Describe the bug We have an application that's using Kryo to serialize/deserialize objects. The exact objects are unknown at compile-time, so they are not registered. This works perfectly fine with Java11. When we switch to Java 17, we start seeing errors such as these - [com.hpe.opencall.ngin.scif.sip.environment.rawjvm.dispatcher.sip.PersistentSipApplicationSessionManager] (EventScannerThread) restoreSession failed. Error during get - get operation failed - com.esotericsoftware.kryo.KryoException: java.lang.IllegalAccessError: failed to access class com.hp.opencall.ngin.scif.sip.mediaua.context.CommonParameterSetImpl from class com.hp.opencall.ngin.scif.sip.mediaua.context.CommonParameterSetImplConstructorAccess (com.hp.opencall.ngin.scif.sip.mediaua.context.CommonParameterSetImpl is in unnamed module of loader 'app'; com.hp.opencall.ngin.scif.sip.mediaua.context.CommonParameterSetImplConstructorAccess is in unnamed module of loader com.esotericsoftware.reflectasm.AccessClassLoader @323cc6)

To Reproduce Dont have a standalone simple program to share,. But there's more info below.

Environment:

  • OS: RHEL 8
  • JDK Version: 17
  • Kryo Version: 5.3.0

Additional context The class in question CommonParameterSetImpl, has 2 public constructors - default and a parameterized one.

public CommonParameterSetImpl() {
        cc = null;
}
public CommonParameterSetImpl(CallContext aCC) {
        cc = aCC;
}

Kryo is being initialized like below -

Kryo kryo = new Kryo();
kryo.setRegistrationRequired(false);
kryo.setReferences(true);
kryo.setOptimizedGenerics(false);

Not sure, why there is "failed to access" in this case. And I'm not sure, what has changed with Java17 that leads to this error. As the same code works perfectly fine with Java11.

vjhpe avatar Aug 25 '22 07:08 vjhpe

@vjhpe: What has changed is that the JDK now denies illegal access to internals by default. See https://openjdk.org/jeps/396. In JDK11 you would only have got a warning message.

What is strange however is that no JDK internals seem to be involved in your example.

Can you provide minimal runnable example that reproduces this issue?

theigl avatar Aug 29 '22 09:08 theigl

Closing due to lack of feedback.

theigl avatar Sep 23 '22 10:09 theigl