Multiline string literals

Ruslan Shevchenko ruslan at
Sat Aug 6 13:30:14 PDT 2011

1. Last submission: 1.4 for multiine string literals is
 which in many aspects differ from first version.

Also, I maintain 'post-morten' final version:
 which can be used as starting point, if Oracle decide to receive
proposals about language direction from external world with reopening
or creation of some analog  of project coin.    [my estimation for
probability of such case is not very hight.]

2.  In general, this proposal describe multiline strings as they
implemented in scala and groovy now.  One problem with this: """ are
IDE-unfriendly: complexity of implementing mulitline string support
for groovy in netbeans shows this.

So, now I think that  """"  symbols in proposal is better change to
pair of  "(    )"   (and '(    )'  for row string literals),  simular
to brackets for multiline string literals in C++0x

Regards !

On Sat, Aug 6, 2011 at 6:12 PM, Per Bothner <per at> wrote:
> On 08/06/2011 03:41 AM, Peter Reilly wrote:
>> Now that jdk7 is released and there will shortly be a process for
>> asking for new small features in jdk8, I would like to ask that
>> support for multiline string literals be considered.
>> This is a long standing request and a specific proposal is contained in:
> I think it would be a mistake for multiline string literals to have
> the ending delimiter be the same as the starting delimiter.  It seems
> lie it would make things more difficult for IDEs.  Using """ also seems
> prone to syntax errors with possibly-confusing error messages.  And it makes
> it harder to scan the text (visually or with tools) for matching delimiters.
> I also think this is a questionable idea:
> String platformDepended="""q
> """;
> is 'q\n' if compiled on Unix and 'q\n\r' if compiled on Windows.
> This make the meaning of a program depend on which platform
> it is compiled on.  Probably not something we want.  You could
> change it to depend on the program it is *run* on, by defining it
> in terms of line.separator - that would make more sense.
> --
>        --Per Bothner
> per at

More information about the coin-dev mailing list