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/
