On Tue, 10 Nov 2020 09:34:56 GMT, Peter Levart <plev...@openjdk.org> wrote:

>> I can see that having a separate IMM_LIST_NULLS type might be necessary to 
>> preserve the allows-null/disallows-null behaviour of indexOf and lastIndexOf 
>> methods...
>> 
>> NOTE ALSO that ListN.equals(o) and ListN.hashCode() are inherited from 
>> AbstractImmutableList:
>> 
>>         @Override
>>         public boolean equals(Object o) {
>>             if (o == this) {
>>                 return true;
>>             }
>> 
>>             if (!(o instanceof List)) {
>>                 return false;
>>             }
>> 
>>             Iterator<?> oit = ((List<?>) o).iterator();
>>             for (int i = 0, s = size(); i < s; i++) {
>>                 if (!oit.hasNext() || !get(i).equals(oit.next())) {
>>                     return false;
>>                 }
>>             }
>>             return !oit.hasNext();
>>         }
>> and
>>         public int hashCode() {
>>             int hash = 1;
>>             for (int i = 0, s = size(); i < s; i++) {
>>                 hash = 31 * hash + get(i).hashCode();
>>             }
>>             return hash;
>>         }
>> 
>> ...which means they will throw NPE when the list contains null. The same 
>> goes for SubList.
>
>> @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.

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

PR: https://git.openjdk.java.net/jdk/pull/1026

Reply via email to