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

Stuart Marks 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'snot 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 isnot 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, andthen 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/

More information about the core-libs-dev mailing list