Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8224678

Compiler Support for JEP 355: Text Blocks (Preview)

    Details

    • Type: CSR
    • Status: Closed
    • Priority: P3
    • Resolution: Approved
    • Fix Version/s: 13
    • Component/s: tools
    • Labels:
      None
    • Subcomponent:
    • Compatibility Kind:
      source
    • Compatibility Risk:
      minimal
    • Compatibility Risk Description:
      Hide
      Since text blocks employ a syntax that is new in the Java language, no pre-existing source code will fail to compile. For programs that process strings, no character can appear in a string derived from a text block that could not already have appeared in a string derived from a string literal. Parsers that work from the grammar of the Java language will obviously have to be updated to understand triple double quoted text blocks in expressions.

      A minor migration incompatibility can occur if a concatenation of string literals, arranged over multiple lines of source code, is turned into a text block whose content spans multiple lines directly. At run time, the string produced from the text block will have newline characters, even if the string literals did not conclude with `\n` escape sequences.

      Text blocks are a preview feature in Java SE 13. It is possible that incompatible changes will be made to text blocks in a later Java SE release, before they become final and permanent. It is also possible that text blocks will be removed in a later Java SE release, without ever having become final and permanent.
      Show
      Since text blocks employ a syntax that is new in the Java language, no pre-existing source code will fail to compile. For programs that process strings, no character can appear in a string derived from a text block that could not already have appeared in a string derived from a string literal. Parsers that work from the grammar of the Java language will obviously have to be updated to understand triple double quoted text blocks in expressions. A minor migration incompatibility can occur if a concatenation of string literals, arranged over multiple lines of source code, is turned into a text block whose content spans multiple lines directly. At run time, the string produced from the text block will have newline characters, even if the string literals did not conclude with `\n` escape sequences. Text blocks are a preview feature in Java SE 13. It is possible that incompatible changes will be made to text blocks in a later Java SE release, before they become final and permanent. It is also possible that text blocks will be removed in a later Java SE release, without ever having become final and permanent.
    • Interface Kind:
      Language construct
    • Scope:
      SE

      Description

      Summary

      Enhance the Java language by introducing text blocks, a more intuitive way to represent multi-line strings than string literals.

      Problem

      In Java, embedding a snippet of HTML, XML, SQL, or JSON in a string literal (JLS 3.10.5) "..." usually requires significant editing with escape sequences (JLS 3.10.6) and concatenation (JLS 15.18.1) before the code containing the snippet will compile. The snippet is often difficult to read and arduous to maintain.

      More generally, the need to denote short, medium, and long blocks of text in a Java program is near universal, whether the text is code from other programming languages, structured text representing golden files, or messages in natural languages. On the one hand, the Java language recognizes this need by allowing strings of unbounded size and content, but on the other hand, it embodies a design default that strings should be small enough to denote on a single line of a source file, and simple enough to escape easily.

      Solution

      The Java language can be regularized by accepting that strings may be large enough to span multiple lines of a source file, and by envisaging that escapes in their content may represent formatting and layout operations as well as individual characters.

      Accordingly, it would improve both the readability and the writeability of a broad class of Java programs to have a linguistic mechanism for denoting strings more literally than a string literal -- across multiple lines and without the visual clutter of escapes. In essence, a two-dimensional block of text, rather than a one-dimensional sequence of characters.

      The following are examples of text blocks:

      String simple = """
                      A simple
                      multi-line
                      text block
                      """;
      String empty = """
                     """;
      String html = """
                    <html>
                        <body>
                            <p>Hello, world</p>
                        </body>
                    </html>
                    """;
      String query = """
                     SELECT `EMP_ID`, `LAST_NAME` FROM `EMPLOYEE_TB`
                     WHERE `CITY` = 'INDIANAPOLIS'
                     ORDER BY `EMP_ID`, `LAST_NAME`;
                     """;
      ScriptEngine engine = new ScriptEngineManager().getEngineByName("js");
      Object obj = engine.eval("""
                               function hello() {
                                   print('"Hello, world"');
                               }
      
                               hello();
                               """);

      Specification

      Proposed changes to the Java Language Specification are attached, and also available online. Because a text block is a constant expression of type String, it is acceptable to use a text block anywhere that a string literal could be used, and vice versa.

      There are no changes to the JVM Specification. A string in the constant pool of a class file (JVMS 4.4.3) has always been independent of Java language rules for string literals, so it is a suitable compilation target for text blocks. A class file does not record whether a string in the constant pool was compiled from a string literal or a text block.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                jlaskey Jim Laskey
                Reporter:
                jlaskey Jim Laskey
                Reviewed By:
                Alex Buckley
              • Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: