Why does Javac reject text blocks ending with four or more " ?
Jim Laskey
james.laskey at oracle.com
Thu Jul 30 21:20:34 UTC 2020
> On Jul 30, 2020, at 4:27 PM, Alex Buckley <Alex.Buckley at oracle.com> wrote:
>
> Since there is evidently interest in consecutive " characters in text blocks, I have updated http://openjdk.java.net/jeps/378#3--Escape-sequences with more discussion and examples.
>
> Alex
>
> On 7/30/2020 8:33 AM, Deepak Vohra wrote:
>> Jim,
>> What I was implying was that four consecutive """" whether at the end of a
>> text block or within a text block are not interpreted as such as these
>> could be 3+1 quotes, and 3 """ are reserved for text blocks.
>> regards,
>> Deepak
>> On Thu, Jul 30, 2020 at 8:17 AM Jim Laskey <james.laskey at oracle.com> wrote:
>>> Deepak,
>>>
>>> It's not clear what you are commenting on.
>>>
>>> As in your description;
>>>
>>> >> cat Empty.java
>>> public class Empty {
>>> public static void main(String... args) {
>>> String s = """
>>>
>>> ""
>>>
>>> """;
>>> System.out.println(s);
>>> }
>>> }
>>> >> java Empty.java
>>>
>>> ""
>>>
>>> As shown in your example;
>>>
>>> >> cat Empty.java
>>> public class Empty {
>>> public static void main(String... args) {
>>> String s = """
>>>
>>> """"
>>>
>>> """;
>>> System.out.println(s);
>>> }
>>> }
>>> >> java Empty.java
>>> Empty.java:5: error: unclosed string literal
>>> """"
>>> ^
>>> Empty.java:7: error: illegal text block open delimiter sequence,
>>> missing line terminator
>>> """;
>>> ^
>>> 2 errors
>>> error: compilation failed
>>>
>>> If you want to include three or more quotes in a text block then escape
>>> (at least) every third quote;
>>>
>>> >> cat Empty.java
>>> public class Empty {
>>> public static void main(String... args) {
>>> String s = """
>>>
>>> \"""\"
>>>
>>> """;
>>> System.out.println(s);
>>> }
>>> }
>>> >> java Empty.java
>>>
>>> """"
>>>
>>>
>>> Cheers.
>>>
>>> -- Jim
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Jul 30, 2020, at 11:04 AM, Deepak Vohra <dvohra16 at gmail.com> wrote:
>>>
>>> Sequences of three characters are reserved for the opening and closing
>>> delimiter and should not occur by user code or incidentally in a text
>>> block. As an example, an empty string literal within a text block, while
>>> apparently permissible, adds three consecutive double quotes as follows:
>>>
>>> String s ="""
>>>
>>> """"
>>>
>>> """;
>>>
>>> On Thu, Jul 30, 2020 at 1:13 AM Alex Buckley <alex.buckley at oracle.com>
>>> wrote:
>>>
>>> " and "" can be used anywhere in a text block except immediately prior
>>> to the closing delimiter. If a text block needs to end with " or "",
>>> then the " and "" may be escaped:
>>>
>>> String s1 = """
>>> ...
>>> \"""";
>>> String s2 = """
>>> ...
>>> \"\"""";
>>>
>>> Writing just """" or """"" runs afoul of the longstanding JLS 3.2 rule
>>> about lexical translation choosing the longest possible token. That is,
>>> during the process of translating characters into the TextBlock token of
>>> the lexical grammar, the discovery of """ is translated as the closing
>>> delimiter of TextBlock, even if a further " follows immediately.
>>>
>>> Alex
>>>
>>> On 7/29/2020 10:05 PM, Jayaprakash Artanareeswaran wrote:
>>>
>>> Hello,
>>>
>>> The following code is rejected by Javac in JDK 15, although JEP 378
>>>
>>> doesn't say anything about it.
>>>
>>>
>>> static final String TEXT_BLOCK = """
>>> 1
>>> """"; // Notice the four quotes here?
>>>
>>> In fact, the JEP says this:
>>>
>>> "The use of the escape sequences \" and \n is permitted in a text block,
>>>
>>> but not necessary or recommended. However, representing the sequence """ in
>>> a text block requires the escaping of at least one " character, to avoid
>>> mimicking the closing delimiter."
>>>
>>>
>>> So, I would imagine it's perfectly okay for up to two consequent quotes
>>>
>>> to be used anywhere in a text block.
>>>
>>>
>>> If this is indeed backed by the spec, can the experts please point me to
>>>
>>> the relevant section?
>>>
>>> Hopefully, I am asking this in the right mailing list.
>>>
>>> Thanks,
>>> Jay
>>>
>>>
>>>
>>>
More information about the amber-dev
mailing list