JEP 186: Collection Literals (original) (raw)
Brian Goetz brian.goetz at oracle.com
Mon Mar 3 13:36:28 PST 2014
- Previous message: Woe is me for using ? super T in a method call (part 2)
- Next message: javadoc small error for Optional.map
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Just to close the loop here, we've reached the conclusion that we will not be pursuing collection literals as a language feature right now, but instead proceeding in the short term with a library-based proposal that is similar to what Stephen has described here, with a few ideas from Guava's ImmutableXxx classes.
Our motivation is largely as outlined earlier in this thread:
The "simple" version of this feature (sets, lists, maps only) is not very satisfying or popular; the "extensible" version of this feature is open-ended, messy, and virtually guaranteed to way overrun its design budget;
The library-based version gives us X% of the benefit for 1% of the cost, where X >> 1;
Value types are coming, and the "what would this feature look like" in a world with value types may well be quite different than in a world without, suggesting it would be questionable to try and do this work before value types;
We are better off focusing our language-design bandwidth on addressing more the foundational issues underlying a library-based version (including: more efficient varargs, array constants in the constant pool, immutable arrays, and support for caching (and reclaiming under pressure) intermediate immutable results).
Separately, I'll try and write up my notes about the various places this exploration led us.
On 2/19/2014 1:02 PM, Stephen Colebourne wrote:
On 21 January 2014 19:39, Brian Goetz <brian.goetz at oracle.com> wrote:
3. The real pain is in Maps, not Lists, Sets, or Arrays. Library-based solutions would be mostly acceptable for the latter, but we still lack a reasonable way to describe pair literals, which is what's in the way of a library-based solution for Map (other than a MapBuilder.) Static methods in interfaces make a library-based solution more practical. With value types, though, library-based solutions for Map become far more practical too. Just to note on this, I previously sent a proposal to core-libs: http://mail.openjdk.java.net/pipermail/lambda-dev/2013-June/010228.html and a proof of concept patch: https://gist.github.com/jodastephen/6659515 The heart of the concept was static methods on interfaces: Collection.empty() Collection.of(T...) List.empty() List.of(T...) Set.empty() Set.of(T...) Map.empty() Map.of(Entry...) Map.Entry.of(K, V)
Each of these methods would return immutable implementations. There is a case for extending the methods to Iterator and other collection types, however these are the most important. These follow the designs of Stream static methods IIRC. I think a complete solution would involve matching static methods on the collection classes as well, eg ArrayList.of(T...) TreeSet.of(T...) I note that the Map variant in the patch is a cunning way to beat the absence of a pair/tuple and generics, but it would require some thought before adoption in the JDK. Stephen
- Previous message: Woe is me for using ? super T in a method call (part 2)
- Next message: javadoc small error for Optional.map
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]