On Wed, 6 Sep 2023 18:34:29 GMT, Mandy Chung <mch...@openjdk.org> wrote:

> This reimplements 
> `sun.reflect.ReflectionFactory::newConstructorForSerialization` with method 
> handles.
> 
> This API currently generates the bytecode which fails the verification 
> because `new C; invokespecial A()` where the given class `C` and invoke a 
> no-arg constructor of `C`'s first non-`Serializable` superclass `A` is not a 
> valid operation per the VM specification. VM special cases the classes 
> generated for reflection to skip verification for the constructors generated 
> for serialization and externalization.  This change will allow such VM hack 
> to be removed.
> 
> A `jdk.reflect.useOldSerializableConstructor` system property can be set to 
> use the old implementation in case if customers run into any compatibility 
> issue.   I expect this change has very low compatibility risk.   This system 
> property is undocumented and will be removed in a future release.

src/java.base/share/classes/jdk/internal/reflect/MethodHandleAccessorFactory.java
 line 127:

> 125:     static ConstructorAccessorImpl 
> newSerializableConstructorAccessor(Class<?> decl, Constructor<?> ctor) {
> 126:         if (!constructorInSuperclass(decl, ctor)) {
> 127:             throw new UnsupportedOperationException(ctor + " not a 
> superclass of " + decl.getName());

Notice in JShell 20, you could do this:

jshell> import sun.reflect.ReflectionFactory;
jshell> var rf = ReflectionFactory.getReflectionFactory()
jshell> var c = rf.newConstructorForSerialization(String.class, 
Boolean.class.getConstructor(boolean.class))
jshell> String d = (String) c.newInstance(false)
jshell> d.length()

which ends up in an NPE for `d.value` is null. This UOE is technically a new 
behavior that should be mentioned in the CSR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15600#discussion_r1317878647

Reply via email to