JEP 186: Collection Literals

[Ali Ebrahimi]

+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
it.

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




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

> On 14 January 2014 17:23, Brian Goetz <brian.goetz at oracle.com> 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)
> https://bugs.openjdk.java.net/browse/JDK-8026106
>
> 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
>
>