[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 01:20:11 UTC 2017

On Dec 8, 2017, at 4:45 PM, John Rose <john.r.rose at oracle.com> 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?

This gets to the heart of a question about how thoroughly we are going to adopt the concept of value-based. I think we want to accept that a sub-collection derived from a value-based collection is itself value-based, whether or not the API point (designed before value based data structures) is supposed to deliver a “view” or not. I.e., a view of a value-based collection is indistinguishable from a non-view, and there are performance costs to maintaining a pretended distinction, so let’s tune our spec. to avoid those costs.

If I'm right about this, perhaps the most natural way to balance Claes's design is to add an offset field to ListN, and allow ListN to project arbitrary slices out of a backing array.

Then we have only two classes (ListN, List12) even when folks are slicing all around their lists. That strikes me as (in terms of number of loaded classes) much more economical than the stuff with a new bespoke SubList class, with it's own new bespoke iterator class. And I think the extra int field (in ListN) will melt into the noise.

— John

More information about the core-libs-dev mailing list