[10?] RFR: 8193128: Reduce number of implementation classes returned by List/Set/Map.of()
stuart.marks at oracle.com
Fri Dec 22 01:31:00 UTC 2017
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
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
Now suppose that we proceed with something similar to Claes' sublist
implementation from webrev open.04,  except that if the requested sublist
matches the bounds of the list, it simply returns 'this'. We'd then have a case
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
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.
More information about the core-libs-dev