Draft language spec for JEP 355: Text Blocks

[Jim Laskey]

Looks pretty good.


___________________________________________________________________________________________________

TextBlock:

" " " { 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.

___________________________________________________________________________________________________


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


You went there. :-)

___________________________________________________________________________________________________

Cheers,

- 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>