JEP 186: Collection Literals

Ali Ebrahimi ali.ebrahimi1781 at
Sun Jan 19 01:45:32 PST 2014

+1 for multi-line strings. This is the feature I missed that every day in
past. So I hacked my own openjdk and add support for that and I enjoy with

This is required patch:
diff --git
--- a/src/share/classes/com/sun/tools/javac/parser/
+++ b/src/share/classes/com/sun/tools/javac/parser/
@@ -637,7 +637,7 @@
                     break loop;
                 case '\"':
-                    while ( != '\"' && != CR && != LF && reader.bp < reader.buflen)
+                    while ( != '\"' && reader.bp < reader.buflen)
                     if ( == '\"') {
                         tk = TokenKind.STRINGLITERAL;

On Sun, Jan 19, 2014 at 11:33 AM, Stephen Colebourne
<scolebourne at>wrote:

> On 14 January 2014 17:23, Brian Goetz <brian.goetz at> wrote:
> > This is a very valid point, and one that has been raised before -- that
> > maybe this doesn't need a language feature, that maybe simply some
> > library changes would be enough.
> >
> > In fact, since the goal at this point is to discuss whether we should
> > move forward or not with the /exploration/ of the language feature, let
> > me restrict the discussion to this point: is this something that needs a
> > language feature, or would library support be enough?  Bear in mind that
> > the cost of even a simple language feature is probably 100x that of a
> > comparable library feature, cost-benefit is an important consideration.
> The key to this question is the value of this feature vs other
> features. From my perspective, there are certainly many other features
> I would consider to be more important. For example, larger changes
> such as value types and properties are far more valuable. Smaller
> changes such as multi-line strings, null-defaulting operator and
> access to maps/lists using array-like syntax are also ahead of this
> one.
> In terms of usage, I don't find myself missing list-literals that
> often (varargs suffice in API design), although I would undoubtedly
> use them (in test code) if they existed. By contrast, map literals
> would change API design and be much more useful as they would suffice
> for named arguments and optional parameters.
> Additional factory methods such as List.of(a, b, c) and
> ArrayList.of(a, b, c) are valuable irrespective of the progress of the
> language change. In my opinion, addition of these methods occur first,
> with language support following (possibly both within JDK9)
> Were collection/map literals to be added I would only support them if
> the resulting objects were immutable.
> I can see more benefit in this feature if linked to value types such
> that a literal is directly/efficiently mapped into memory/bytecode
> without the need for vast amounts of bytecode as with current
> approaches.
> Stephen

More information about the lambda-dev mailing list