On Tue, 17 Nov 2020 20:04:58 GMT, Stuart Marks <sma...@openjdk.org> wrote:
>>> @plevart wrote: >>> >>> > But the question is how does having a separate CollSer.IMM_LIST_NULLS >>> > type prevent that from happening? >>> >>> When a serialized list with IMM_LIST_NULLS is deserialized on an older JDK, >>> it'll throw InvalidObjectException since that tag isn't valid on older >>> JDKs. Obviously this is still an error, but it's a fail-fast approach that >>> avoids letting nulls leak into a data structure where they might cause a >>> problem some arbitrary time later. >>> >> >> Yes, but that is JDK16+ vs. JDK15- and not App V1 vs. App V2 thing. If both >> apps run on JDK16+, there will be no exception. >> >> What I'm trying to say is that the same problem of injecting unexpected >> nulls via serialization/deserialization can happen also if App V2 starts >> using ArrayList to construct the data structure and serialize it while App >> V1 deserializes it and expects non-null values only. App V1 would already >> have to guard against null values during deserialization in that case, >> because possibility of null values in deserialized data structure is nothing >> new for App V1. > > @plevart wrote: >> Yes, but that is JDK16+ vs. JDK15- and not App V1 vs. App V2 thing. If both >> apps run on JDK16+, there will be no exception. > > Sure, the IMM_LIST_NULLS tag only helps with serialization compatibility > across JDK releases. There are lots of ways an app can make incompatible > changes to the serialized forms of its objects that we have no way of > detecting. >> Sure, the IMM_LIST_NULLS tag only helps with serialization compatibility >> across JDK releases. > I would say it goes the other way - it worsens the serialization compatibility. OK, I was imprecise. The IMM_LIST_NULLS tag has an effect only on serialization across JDK releases, not changes to the application's serialization format using the same JDK release, or even on many changes to the app's serialization format across JDK releases. By "helps with serialization compatibility" I meant that this new serialized form helps the general issue of serialization compatibility (really, incompatibility) by failing fast in certain cases, instead of possibly allowing polluted data to leak into the receiving application and causing some arbitrary exception later during the run. But as you noted last, this is a different kind of object, and it has different behavior, so it needs a different encoding in the serialized form. I'll update this PR shortly with changes to fix null handling and other issues. ------------- PR: https://git.openjdk.java.net/jdk/pull/1026
