Draft language spec for JEP 355: Text Blocks
alex.buckley at oracle.com
Tue May 21 00:57:21 UTC 2019
We already know the migration incompatibility of how:
"SELECT ..." +
"FROM ..." +
is not ever equals() to:
because of the extra line terminators in the string derived from the
text block. There will be a further migration incompatibility if:
is not always == to:
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
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
> Sent from my iPad
>> On May 20, 2019, at 7:08 PM, Alex Buckley <alex.buckley at oracle.com>
>> Please see
>> 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.
More information about the amber-spec-experts