This is in reply to:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-November/036331.html
+ static <E> List<E> of(E... es) {
+ for (E e : es) {
+ Objects.requireNonNull(e);
+ }
+ // NOTE: this can allow a null element to slip through
+ return Collections.unmodifiableList(Arrays.asList(es));
+ }
Even as a skeletal implementation, this one has to be changed to be
truly immutable, right? It currently returns a view of the (mutable)
argument array rather than new storage. Sorry for not providing a
proper test:
String[] array = { "bar", "baz" };
List<String> list = of(array);
System.out.println(list); // [bar, baz]
array[0] = "foo";
System.out.println(list); // [foo, baz]
> Regarding the number of fixed-arg overloads, having five List and Set elements
> seemed too few, and even eight key-value pairs for Map seemed too few. I've
> somewhat arbitrarily chosen ten elements and pairs. It seems high enough to
> catch most cases with the fixed-arg overloads, and we still have the varargs
> as
> an escape hatch.
Has anyone been able to quantify the advantage of having these
overloads as opposed to having the varargs versions only? Is it a
matter of performance?
I ask because the overloads seem like warts on the APIs (which is a
shame -- List and Set are such important APIs). I'm imagining a
future where:
1. We add these overloads for performance gains now.
2. But they're all skeletal implementations that aren't that perfomant
anyway. Efficient versions don't make it into Java SE 9. People that
care a lot about performance avoid using these ones.
3. A few years later, varargs performance or some other language / VM
/ compiler-level change renders the overloads obsolete.
-Michael
