Draft language spec for JEP 355: Text Blocks

Jim Laskey james.laskey at oracle.com
Tue May 21 12:30:46 UTC 2019

Looks pretty good.



" " " { the ASCII SP character } LineTerminator { TextBlockCharacter } " " "

 "the ASCII SP character" in the open delimiter is currently implemented as any "white space" but not a line terminator. Later on you state "zero or more white spaces".


The string represented by a text block is not the literal sequence of characters in the content. Instead, the string represented by a text block is the result of processing the content, as follows:

I think this could be reworded so that the importance of order is made clear. Later on you state "Interpreting escape sequences last allows", but it's still not clear the order of 1 & 2 is important. In the JEP we described them as "steps". Stages might work as well.


    rate > 0 &&
    rate <= MAX_REFRESH_RATE
public void setRefreshRate(int rate) { ... }

You went there. :-)



- Jim

> On May 20, 2019, at 8: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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20190521/5a71559e/attachment.html>

More information about the amber-spec-experts mailing list