[10?] RFR: 8193128: Reduce number of implementation classes returned by List/Set/Map.of() (original) (raw)
Andrej Golovnin andrej.golovnin at gmail.com
Sat Dec 9 10:24:28 UTC 2017
- Previous message: [10?] RFR: 8193128: Reduce number of implementation classes returned by List/Set/Map.of()
- Next message: [10?] RFR: 8193128: Reduce number of implementation classes returned by List/Set/Map.of()
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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().
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
- Previous message: [10?] RFR: 8193128: Reduce number of implementation classes returned by List/Set/Map.of()
- Next message: [10?] RFR: 8193128: Reduce number of implementation classes returned by List/Set/Map.of()
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]