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