On Wed, 20 May 2026 23:57:11 GMT, Dan Smith <[email protected]> wrote:
>> I thought this might break java.lang.Number, but after checking this >> shouldn't hurt. Will make this change. > > Oh, that's interesting. What happens to BigInteger under this rule (a > Serializable identity class that extends a Serializable abstract value > class)? How is it deserialized? > > Maybe we're going to have to be more permissive with stateless abstract value > classes... So here the first non-serializable superclass that can execute normal construction is `java.lang.Object`. Serialization spec for now says `BigInteger` is allocated and `Object`'s no-arg constructor is called, and the fields are injected. So yes, here `java.lang.Number` initialization in the middle must be skipped and that doesn't work. It worked with `java.lang.Integer` and other wrapper classes because they use their deserialization factory instead of this allocate, call super constructor, and fill procedure. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/2350#discussion_r3278144741
