JEP 186: Collection Literals

Zhong Yu zhong.j.yu at
Tue Jan 21 19:17:36 PST 2014

On Tue, Jan 21, 2014 at 4:59 PM, Roel Spilker <r.spilker at> wrote:
> As a Lombok developer I have quite some experience with value types. I do
> think value types are very important.
> That said, I notice that most of them are used to return two or more values
> from a method. In concurrent programming this is even more important. The
> current workaround in AtomicMarkableReference and AtomicStampedReference is
> to return one value and put the other value in the array that was passed as
> a parameter.
> There is a way to have multiple return values without introducing new types
> (at least for the java programmer). At the risk of getting into a syntax
> discussion, one possible way would be to only allow the results to be
> assigned to fields, local variables or parameters directly. Example:

This proposal is going to complicate overload resolution, type
inference, override equivalency check, etc, which are already very

It breaks a very basic assumption that a method returns a type; for
example, what `java.lang.reflect.Method.getReturnType()` should do

And the limitation on referencing the return value(s) is quite
inconvenient, for example, how do we project the returned tuple to the
2nd element? If foo() returns Pair<int, String> instead, we could do

Zhong Yu

> public {int, String} foo() {
>   return {1, "foo"};
> }
> void printFoo() {
>   {int count, String message} = foo();
>   for (int i = 0; i < count, i++) System.out.println(message);
>   // call a method using the multiple results
>   String repeated = repeat(foo(), false);
> }
> String repeat(int count, String message, boolean newLines) {
>   String result = "";
>   for (int i = 0; i < count, i++) {
>     result += message;
>     if (newLines) result += "\n";
> }
> Would having multiple return values be part of the design space?
> On Tue, Jan 21, 2014 at 8:39 PM, Brian Goetz <brian.goetz at> wrote:
>> So, there's been some good discussion regarding the proper scope of
>> Collection Literals, so let me summarize what I heard.  I am sensing
>> that the center of gravity is roughly behind these points:
>> 1.  A "collection literals" feature that only worked for the built-in
>> types (e.g., List, Set, Map), but was not extensible to user-defined
>> types, would be disappointing.
>> 2.  Having these literals be mutable would be surprising.
>> 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.
>> 4.  This feature is less critical that many other features, such as
>> value types, tuples, or primitive specialization of generics.  For the
>> most part, this feature is a nice-to-have, but no one would vote for
>> delaying value types because of it.
>> 5.  The underlying mechanics (varargs at the language level; lack of
>> constant pool support for arrays at the bytecode level; ad-hoc support
>> for caching of (and GC'ing under memory pressure) intermediate immutable
>> results) remain a limiting factor, even with syntactic sugar.  Working
>> on these foundational issues might provide more bang-for-buck.
>> Of course, in a community of 10M, there will be some range of opinion,
>> but the goal of posting this here was to sanity-check our assumptions
>> about priorities.  Thanks to all who provided feedback!

More information about the lambda-dev mailing list