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.buck...@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
