Déjà preview

JEP 368: Text Blocks (Second Preview)

Chris Stewart
JEP 368
© Shutterstock / AliceRubik

Remember text blocks? That’s right, they were a preview feature in the recently released Java 13! Now that some time has passed, the community has a feel for them and where there’s room for improvement. With JEP 368, Jim Laskey proposes a second text blocks preview, this time with two more escape sequences. Let’s take a closer look.

When JDK 13 was released on September 17, 2019, it brought text blocks with it as a preview feature. On that day we published an article by Tim Zöller about why text blocks are worth the wait. It now seems like users will have to wait a little longer to see text blocks become a full-fledged feature thanks to a new Java Enhancement Proposal, JEP 368, written by Jim Laskey, who also wrote the original proposal introducing text blocks as a preview feature in JDK 13, JEP 355.

JEP 368: Text Blocks (Second Preview)

So why have text blocks come around for a second preview? There’s a lot of developers out there who have are keen to get this feature out of preview, but if something is worth doing then it’s worth doing well. The same applies to text blocks. It seems that some developers have struggled with white space and newline control. Under the Motivation section of JEP 368, Jim Laskey wrote:

Still, it is impossible to predict the role of every string in Java programs. Just because a string spans multiple lines of source code does not mean that newline characters are desirable in the string. One part of a program may be more readable when strings are laid out over multiple lines, but the embedded newline characters may change the behavior of another part of the program. Accordingly, it would be helpful if the developer had precise control over where newlines appear, and, as a related matter, how much white space appears to the left and right of the “block” of text.

JEP 368’s second preview round hopes to resolve these teething problems with the addition of two new escape sequences that manage explicit white space and newline control.

SEE ALSO: Java 14: Six JEPs proposed to target JDK 14

New escape sequences

Here’s what JEP 368 has to say about the two new escape sequences:

First, the \<line-terminator> escape sequence explicitly suppresses the insertion of a newline character.

For example, it is common practice to split very long string literals into concatenations of smaller substrings, and then hard wrap the resulting string expression onto multiple lines:

String literal = "Lorem ipsum dolor sit amet, consectetur adipiscing " +
                 "elit, sed do eiusmod tempor incididunt ut labore " +
                 "et dolore magna aliqua.";

With the \<line-terminator> escape sequence this could be expressed as:

String text = """
                Lorem ipsum dolor sit amet, consectetur adipiscing \
                elit, sed do eiusmod tempor incididunt ut labore \
                et dolore magna aliqua.\

Second, the \s escape sequence simply translates to a single space (\u0020).

Escape sequences aren’t translated until after incident space stripping, so \s can act as fence to prevent the stripping of trailing white space. Using \s at the end of each line in this example guarantees that each line is exactly six characters long:

String colors = """
    red  \s
    blue \s


To remove or not to remove white space, that is the question

The final change from JEP 355 is that under the Alternatives header, instead of Removal of incidental white space, it now reads Do not remove incidental white space:

If Java introduced multi-line string literals without support for automatically removing incidental white space, then many developers would write a method to remove it themselves, or lobby for the String class to include a removal method. However, that implies a potentially expensive computation every time the string is instantiated at run time, which would reduce the benefit of string interning. Having the Java language mandate the removal of incidental white space, both in leading and trailing positions, seems the most appropriate solution. Developers can opt out of leading white space removal by careful placement of the closing delimiter.

As yet, JEP 368 is not targeted to an upcoming JDK but its status as a candidate means that it has been accepted for inclusion in the roadmap by the OpenJDK lead. There’s still time for it to be targeted to JDK 14. Watch this space.

You can see JEP 368 in all its glory here.

Chris Stewart
Chris Stewart is an Online Editor for He studied French at Somerville College, Oxford before moving to Germany in 2011. He speaks too many languages, writes a blog, and dabbles in card tricks.

Inline Feedbacks
View all comments