<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Looks pretty good.<div class=""><br class=""></div><div class=""><div class=""><br class=""></div><div class="">___________________________________________________________________________________________________</div><div class=""><br class=""></div><div class="">TextBlock:</div><div class=""><br class="">" " " { the ASCII SP character } LineTerminator { TextBlockCharacter } " " "</div><div class=""><br class=""></div><div class=""><br class=""><br class=""><div class=""> "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".</div><div class=""><br class=""></div><div class=""><div class="">___________________________________________________________________________________________________</div><div class=""><br class=""></div></div><div class=""><p style="padding: 0em 0.2em; margin: 1ex 0em;" class="">The string represented by a text block is <em class="">not</em> 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:</p><div class=""><br class=""></div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class=""><div class=""><div class="">___________________________________________________________________________________________________</div><div class=""><br class=""></div></div><div class=""><br class="webkit-block-placeholder"></div></div><div class="">@Precondition("""<br class="">    rate > 0 &&<br class="">    rate <= MAX_REFRESH_RATE<br class="">""")<br class="">public void setRefreshRate(int rate) { ... }</div></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">You went there. :-)</div><div class=""><br class=""></div><div class=""><div class=""><div class="">___________________________________________________________________________________________________</div><div class=""><br class=""></div></div></div><div class="">Cheers,</div><div class=""><br class=""></div><div class="">- Jim</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On May 20, 2019, at 8:08 PM, Alex Buckley <<a href="mailto:Alex.Buckley@oracle.com" class="">Alex.Buckley@oracle.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Please see <a href="http://cr.openjdk.java.net/~abuckley/jep355/text-blocks-jls.html" class="">http://cr.openjdk.java.net/~abuckley/jep355/text-blocks-jls.html</a> for JLS changes that align with the JEP.<br class=""><br class="">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.<br class=""><br class="">Alex<br class=""></div></div></blockquote></div><br class=""></div></div></div></body></html>