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

Andrej Golovnin andrej.golovnin at gmail.com
Sat Dec 9 10:24:28 UTC 2017


Hi Claes,

> 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.

Not for me. java.util.ArrayList is a subclass of AbstractList and is serializable.
And you can use j.u.ArrayList to implement the #subList-method in a subclass of
AbstractList without violating the @implSpec in AbstractList#subList.

And as John already mentioned AbstractList is not a part of the Public API of
the lists returned by the List#of()-methods. So the only spec you should care
about is the one defined in List#subList(). And this spec says nothing about
whether the returned instance should be searializable or not.

> As time is likely up for getting this into 10 then I guess we might as well
> take a step back and do this right for 11. I suspect we'll need a CSR for
> this RFE regardless.
> 
> Keeping it all down to two classes as you suggest allows any mixed usage to
> stay in the realm of bimorphism which might bring a considerable speedup
> in some cases, and the reduction in number of implementation classes
> loaded is a boon. Having all methods in ListN account for the offset might
> cost us a few percent here and there, though.
> 
> An int offset on ListN would actually be footprint neutral compared to the
> pre-existing implementation which pulls in the int modCount from AbstractList.

I really like the idea from John to use List12 and ListN for sublists as it would give
us for free the fast implementations for the methods like indexOf, lastIndexOf, etc. even
for sublists. But I would not use offset. Do you remember the problem with String#substring()
when the #substring()-method has returned a view over very huge String object
which then could not be garbage collected due to a reference from the substring?

I would just add a new constructor to ListN:

ListN(E[] elements, int fromIndex, int toIndex)

to copy elements from the parent list. And this would allow us to keep 
the implementation of the ListN class as is.

One more thing: Could you please add specialised implementations also
for the following methods:

List.forEach(Consumer)

List.spliterator()
  For List12 when List12.size() == 1 please use Collections.singletonSpliterator()
  (this method should be moved to the Spliterators class and be public).
  For List12 when List12.size() == 2 please use Arrays.spliterator().
 
  For ListN when List.isEmpty() == true please use Spliterators.emptySpliterator​()
  and otherwise use Arrays.spliterator().


> http://cr.openjdk.java.net/~redestad/8193128/open.04/

In case you still would like to use the SubList class:

115             int size;

The size field should be final.

Thanks!

Best regards,
Andrej Golovnin



More information about the core-libs-dev mailing list