The motivation section ought to more directly survey what we have now: - Collections.emptyList/emptySet/emptyMap - Collections.singletonList/singleton/singletonMap - Arrays.asList - EnumSet.of (varargs, plus some overloads) - Stream.empty and Stream.of (singleton plus varargs) - Constructors that, by convention, always have a variant that constructs an empty collection and another to copy the contents of an existing collection
This helps to clarify that there are multiple goals: - Provide some default methods in List/Set/Map for easier access to existing behavior (following the pattern of EnumSet) - Add new functionality to create immutable Sets/Maps for 2 <= n <= small number. - (Maybe?) varargs methods to create immutable Sets/Maps or arbitrary size. - Provide an array-less implementation of immutable Lists for 2 <= n <= small number. ---------- "If a mutable collection is desired, the contents of an immutable collection can easily be copied into a collection type of the caller's choice." ... "If there are sufficient use cases to support convenient creation of mutable collections, factory methods for particular mutable collection classes could be added." Following the existing convention, it might make more sense to make these constructors: ArrayList() ArrayList(Collection<? extends E>) ArrayList(E...) // this is new ---------- "Converting a mutable collection into an immutable one is more difficult." In principle, if you've got a varargs List creation method, there's nothing to stop you from overloading it with an Collection/Iterable/Stream version. Same functionality, although this might encourage users to think that larger collections will behave properly. (You could pass in a large array to the varargs method, but presumably most users will be passing in small varargs lists.) ---------- I was curious about other collections that might benefit. - It turns out Queue and Deque are pretty useless as immutable data structures. - SortedSet and SortedMap could be useful. - Stream could probably be made consistent with the overloading scheme you settle on; EnumSet, too, if it's different. - There might be some use cases for Iterator; likely doesn't carry its weight, though. —Dan On Jul 16, 2014, at 6:46 PM, Stuart Marks <stuart.ma...@oracle.com> wrote: > Hi all, > > Please review this draft JEP for Convenience Factory Methods for Collections: > > https://bugs.openjdk.java.net/browse/JDK-8048330 > > Brief background: several times over the years there have been proposals to > add "collection literals" to the language. The most recent round of this was > in regard to JEP 186, a research JEP to explore this topic. That effort was > concluded by Brian Goetz, as summarized in this email: > > http://mail.openjdk.java.net/pipermail/lambda-dev/2014-March/011938.html > > Essentially, the idea of adding collection literals to the language was set > aside in favor of adding some library APIs, not entirely unlike collection > literals, that make it more convenient to create collections. That's what > this proposal is. > > Share and enjoy, > > s'marks >
