Hi Stuart,
Good to see these implementations finally appear. I have a few comments:
- What's the point of 11 overloaded List.of() methods for 0 ... 10-arity
if you then invoke the var-args ListN(E...input) constructor that does
the array cloning with 8 of them? The same for Set.of()... I suggest
that you don't clone the array in ListN(E... input) constructor but only
in List.of(E ... input) method.
- {Set0, Set1, Set2}.contains(null) return false, but
SetN.contains(null) throws NPE. All List{0,1,2,N}.contains(null) return
false. What should be the correct behavior?
ConcurrentHashMap.keySet().contains(null) throws NPE for example.
- SetN.probe(E pe) and MapN.probe(K pk) invoke ee.equals(pe) and
ek.equals(pk) respectively. Although it should be logically equivalent,
it has been a practice in collections to invoke the .equals() method on
the passed-in argument rather than on individual elements of the collection.
- Should unchecked exceptions from constructors be wrapped with
InvalidObjectException in SerialProxy.readResolve() or does the
Serialization infrastructure already perform the equivalent?
Regards, Peter
On 05/04/2016 06:55 AM, Stuart Marks 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
