A new instance is being created each time for size-zero lists/sets/maps. This should return a singleton.
The serialization proxy is reminiscent of those in JSR-310 but less space efficient. Once per stream, the proxy will write "java.util.ImmutableCollections.SerialProxy", whereas the JSR-310 one is "java.time.Ser". Thats about 29 bytes more than it needs too. ie. a package-scoped java.util.Ser would be more efficient. There are no messages for IndexOutOfBoundsException. Like Peter, I'm not convinced that extending AbstractList is the way to go, although I can see arguments both ways. equals() and hashCode() could be optimized on the size 0, 1 and 2 classes, as probably can some other methods. Should spliterator() should be overridden to add the IMMUTABLE flag? For maps, I implemented this years ago which may be of interest: http://commons.apache.org/proper/commons-collections/xref/org/apache/commons/collections4/map/Flat3Map.html#L72 I disagree with altering the iteration order. Guava's ImmutableSet and ImmutableMap have reliable iteration specified to match creation order. This aspect of the design is very useful. Stephen On 4 May 2016 at 05:55, Stuart Marks <stuart.ma...@oracle.com> wrote: > Hi all, > > This is a reimplementation of collections created by the JEP 269 convenience > factory methods. These implementations are overall quite a bit smaller than > their conventional collections counterparts, particularly at small sizes. > Lookup performance for the hash-based structures (Set and Map) is not > particularly fast, though in most cases it's comparable to TreeSet/TreeMap. > Further improvements are likely possible. > > There are no API changes in this changeset. > > Please review: > > http://cr.openjdk.java.net/~smarks/reviews/8139233/webrev.0/ > > JEP link: > > http://openjdk.java.net/jeps/269 > > Thanks, > > s'marks
