RFR(m): 8139233 add initial compact immutable collection implementations

[Stephen Colebourne]

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