On Fri, 5 Jun 2026 15:56:53 GMT, Alan Bateman <[email protected]> wrote:
>> Chen Liang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Apply suggestions from code review >> >> Co-authored-by: Viktor Klang <[email protected]> > > src/jdk.unsupported/share/classes/sun/reflect/ReflectionFactory.java line 77: > >> 75: * strictly-initialized fields >> 76: */ >> 77: public Constructor<?> newConstructorForSerialization(Class<?> cl, > > The 1-arg newConstructorForSerialization returns null, the 2-arg > newConstructorForSerialization may return null or throw UOE. Is that existing > behavior (before value classes and strict-init fields), just checking. > > (although this is the jdk.unsupported module, the ReflectionFactory "API" is > there for 3rd party serialization libraries to continue to work until legacy > serialization goes away) That is the existing behavior on mainline, from `jdk.internal.reflect.ReflectionFactory::generateConstructor`. (The 2-arg version never returns null, that might be a misunderstanding from your part) The 1-arg version on mainline automatically finds a suitable no-arg constructor from the first non-serializable superclass of the specified class, returns null the specified class is not serializable, no constructor is suitable, but it ensures the found constructor never fails with a UOE once passed to `generateConstructor`. The 2-arg version just has a shortcut to avoid generation if `constructorToCall` is declared in the specified class. It delegates everything to `generateConstructor`, which is a method that either returns successfully or throws UOE in `MethodHandleAccessorFactory::newSerializableConstructorAccessor`. Thus, when I updated these APIs, I made the 1-arg version return null for a value class or a strict field calss, and the 2-arg version throw UOE. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/2350#discussion_r3363932581
