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

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