Draft language spec for JEP 355: Text Blocks
Alex Buckley
alex.buckley at oracle.com
Tue May 21 00:57:21 UTC 2019
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
>
More information about the amber-spec-experts
mailing list