com.oracle.svm.reflect.serialize

Class SerializationSupport.StubForAbstractClass

java.lang.Object

com.oracle.svm.reflect.serialize.SerializationSupport.StubForAbstractClass

All Implemented Interfaces:

Serializable

Enclosing class:

SerializationSupport

public static final class SerializationSupport.StubForAbstractClass
extends Object
implements Serializable

Method MethodAccessorGenerator.generateSerializationConstructor dynamically defines a SerializationConstructorAccessorImpl type class. The class has a newInstance method which news the class specified by generateSerializationConstructor's first parameter declaringClass and then calls declaringClass' first non-serializable superclass. The bytecode of the generated class looks like:

 jdk.internal.reflect.GeneratedSerializationConstructorAccessor2.newInstance(Unknown Source)
 [bci: 0, intrinsic: false] 
 0: new #6 // declaringClass 
 3: dup
 4: aload_1
 5: ifnull 24
 8: aload_1
 9: arraylength
 10: sipush 0
 ...
 

The declaringClass could be an abstract class. At deserialization time, SerializationConstructorAccessorImpl classes are generated for the target class and all of its serializable super classes. The super classes could be abstract. So it is possible to generate bytecode that new an abstract class. In JDK, the super class' generated newInstance method shall never get invoked, so the "new abstract class" code won't cause any error. But in Substrate VM, the generated class gets compiled at build time and the "new abstract class" code causes compilation error. We introduce this StubForAbstractClass class to replace any abstract classes at method generateSerializationConstructor's declaringClass parameter place. So there won't be "new abstract class" bytecode anymore, and it's also safe for runtime as the corresponding newInstance method is never actually called.

See Also:

Serialized Form

Method Summary

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait