[10?] RFR: 8193128: Reduce number of implementation classes returned by List/Set/Map.of()
John Rose
john.r.rose at oracle.com
Sat Dec 9 00:45:41 UTC 2017
On Dec 7, 2017, at 3:41 PM, Claes Redestad <claes.redestad at oracle.com> wrote:
>
> - the ListFactories test didn't explicitly verify that sublists retrieved from various List.of() impls aren't Serializable. Added tests to check no sub-list is Serializable,
> and as a bonus this test now verifies that List.of(...).subList(...) behave like their List.of(..) counterparts in most other ways.
List::subList is a view into a backing list. But the
story is different for the value-based lists produced
by List.of.
If L is a value-based class, then it seems to me
a meaningless (therefore useless) distinction to
call L::subList a "view". A slice of a value-based list
can only be another value-based list, because there
is nothing else to slice, besides the component values
of the original list.
So I think we should move forward more confidently
with subList here, and say that List.of(a,b,c).subList(1,2)
is equivalent in all ways to List.of(b,c), and so on.
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?
— John
More information about the core-libs-dev
mailing list