[10?] RFR: 8193128: Reduce number of implementation classes returned by List/Set/Map.of()

[Stuart Marks]

John Rose wrote:

> Can anyone point out a reason why the value based
> lists of List.of() should serialize while the value based
> lists of List.of().subList() should not?  Or is there some
> reason we should not allow subList to produce value
> based lists?

>> I think one can interpret the @implSpec in AbstracList::subList to suggest
>> that the implementation retrieved will subclass AbstractList, which implies
>> it's*not*  Serializable. As we move away from AbstractList then we can of
>> course choose our own spec, but since it's established behavior I tried as
>> best I could to retrofit behavior…

> Maybe you are right about that, but AbstractList is*not*  part of the API
> of the List returned by List.of, so you are free to do whatever is right
> for the value-based list, ignoring all parts of AbstractList that are not
> immediately valuable to you.
> 
> (Yes, someone could "notice" that the result of List.of seems to be
> castable to AbstractList, and*then*  lodge a complaint that its sublist
> is serializable, but that's a forced scenario; if we deem it is a real
> bug to fix, at some date far in the future, we can fix it by removing
> AbstractList from the supers of the List.of result.)

Right, there is no requirement that subList() return an instance of AbstractList.

We have a blanket value-based statement over all these implementations. Anybody 
who cares whether subList() returns the same or a different instance, for 
example using References on them, is performing an identity-sensitive operation, 
which violates the value-based admonition.

(Should use of References be added to the list of identity-sensitive operations 
in ValueBased.html?)

I do have a bit of an issue with something like List.of().subList(0,0) returning 
'this', since in this case the sublist will be serializable. This is an outlier, 
because, most existing sublists of the conventional collections aren't 
serializable. And in JDK 9 (and probably JDK 10) sublists of immutable lists 
aren't serializable, since the immutables' sublist implementation is inherited 
from AbstractList.

Now suppose that we proceed with something similar to Claes' sublist 
implementation from webrev open.04, [1] except that if the requested sublist 
matches the bounds of the list, it simply returns 'this'. We'd then have a case 
where

     List.of().subList(0, 0) is serializable
     List.of(1).subList(0, 0) is not serializable
     List.of(1).subList(0, 1) is serializable

and in general

     Object[] a = ...
     List.of(a).subList(m, n) ??? serializable ???

I'd like to avoid situations like this, where a sublist (and in general, view 
collections) are sometimes serializable and sometimes not, depending upon the 
input data. Instead, I'd like a blanket assertion that view collections are not 
serializable.

Now this should be considered distinct from whether view collections are 
value-based; I'm fine with considering view collections to be value-based. It's 
just that some value-based collections are serializable and others aren't. In 
particular, given a serializable, value-based list, a sublist should not be 
serializable but it can be value-based. A sublist of a sublist should also not 
be serializable and can be value-based, and in this case we can do 
short-circuiting such as 'return this' if we like.

s'marks


[1] http://cr.openjdk.java.net/~redestad/8193128/open.04/