Draft language spec for JEP 355: Text Blocks

[Alex Buckley]

We already know the migration incompatibility of how:

"SELECT ..." +
"FROM ..." +
"WHERE ..."

is not ever equals() to:

"""
SELECT ...
FROM ...
WHERE ..."""

because of the extra line terminators in the string derived from the 
text block. There will be a further migration incompatibility if:

"""
Hello world"""

is not always == to:

"Hello world"

because of the lack of guaranteed string interning. Are you saying that 
the freedom to compile text blocks as dynamically-computed constants 
(rather than as static constants; see JVMS12 5.1) is more important than 
the space savings and identity guarantees from interning? I understand 
that starting off loose allows tightening later, but the loose behavior 
is significant.

Alex

On 5/20/2019 4:46 PM, Brian Goetz wrote:
> I wonder if we want to be cagey about committing to interning, which
> is another way to say we must translate too a constant string info.
> In the future, alternate condy- based representations may seem
> desirable and we don’t want to be painted into a translation by
> overspecification.
>
>
>
> Sent from my iPad
>
>> On May 20, 2019, at 7:08 PM, Alex Buckley <alex.buckley at oracle.com>
>> wrote:
>>
>> Please see
>> http://cr.openjdk.java.net/~abuckley/jep355/text-blocks-jls.html
>> for JLS changes that align with the JEP.
>>
>> Text blocks compile to the same class file construct as string
>> literals, namely CONSTANT_String_info entries in the constant pool.
>> Helpfully, the JVMS is already agnostic about the origin of a
>> CONSTANT_String_info, making no reference to "string literals".
>> Therefore, there are no JVMS changes for text blocks, save for a
>> tiny clarification w.r.t. annotation elements.
>>
>> Alex
>