skip to content

Are text blocks fully interchangeable with regular String literals, and what subtle pitfalls exist?

level: seniorimportance: should knowfreq 45%

answer

  1. Compile-time constant String, interned -> == works
  2. Usable in case labels / annotations
  3. No built-in interpolation; use formatted()
  4. Whitespace + trailing-newline pitfalls
  5. Tabs vs spaces shift the minimum

basics

~20 s

Yes — a text block compiles to an ordinary String, so it can go anywhere a String literal can, including switch labels and annotations. Pitfalls are mostly about hidden whitespace, the trailing newline, and the required newline after the opening delimiter.

solid answer

~50 s

A text block is just another form of String literal: it is a compile-time constant of type java.lang.String, so two literals with equal resulting text are equal and interned to the same object, and a text block is usable anywhere a constant string is required — case labels, annotation values, constant expressions. The subtleties are about content, not type. The opening delimiter must be followed by a newline (you cannot open and put text on the same line). Incidental-whitespace stripping plus trailing-whitespace removal means what you see in source is not always what you get, so the closing delimiter's column and any \s matter. A trailing newline is present iff the closing delimiter is on its own line. Editors/formatters can silently change indentation. For interpolation, Java has no built-in placeholder syntax; you still use formatted (the instance method formatted, equivalent to String.format) or concatenation. Mixing tabs and spaces in the indentation can shift the computed minimum unexpectedly.

code

java · 10 lines
java
// Usable as a constant; interned like any literal
static final String GREETING = """
        hi""";          // "hi"
boolean same = (GREETING == "hi");   // true (both interned constants)

// No interpolation: use formatted()
String name = "Ada";
String msg = """
        Hello, %s!
        """.formatted(name);   // "Hello, Ada!\n"

go deeper

for a junior

Know a text block is just a String and can be used like one.

for a middle

Explain that there is no interpolation and that you use formatted() or +, plus the main whitespace/newline pitfalls.

for a senior

Discuss compile-time-constant/interning equivalence, use in case labels and annotations, tabs-vs-spaces subtleties, and review-time invisibility of the value.

for a principal

Weigh maintainability (formatter pinning, fragile alignment, externalizing large payloads), the withdrawn String Templates history, and team conventions for safe, reviewable text-block usage.

## Type and constant equivalence A **constant expression** in Java is one the compiler can fully evaluate at compile time; string literals are constant expressions, and so are text blocks. Consequences: - A text block has type `java.lang.String` — there is no separate type. Anything accepting a `String` accepts it. - Because both are compile-time constants that get **interned** (placed in the JVM's shared string pool), a text block and a regular literal that resolve to the *same* characters are not just `.equals()` — they are the **same reference** (`==` is true). - Being a constant expression, a text block can be used where the language *requires* a constant string: `case` labels in a `switch`, annotation element values, and `static final` constant initializers. ```java String a = """ hi"""; String b = "hi"; // a == b is true (both interned constants) ``` ## The genuine pitfalls — all about content, not type 1. **Opening line rule.** `"""text` does not compile. The opening delimiter must be followed only by optional whitespace and a line terminator. This is the most common first mistake. 2. **Invisible whitespace.** The value depends on (a) the common minimum indentation, which depends on every non-blank line *and the closing-delimiter line*, and (b) trailing-whitespace removal. So copy-pasting or re-indenting can silently change the string. Reviewers cannot "see" the value from the source alone — use `\s` and deliberate closing-delimiter placement to make intent explicit. 3. **Trailing newline.** Present only when the closing delimiter is on its own line. Forgetting this is a frequent source of off-by-one-newline bugs (e.g. SQL or HTTP payloads). 4. **Tabs vs spaces.** Indentation is counted in *characters*, so a single tab counts as one regardless of display width. Mixing tabs and spaces can make the computed minimum smaller or larger than it visually appears. 5. **No interpolation.** Unlike some languages, Java text blocks have **no** built-in `${...}` substitution. You combine them with values via `formatted(...)` (an instance method equivalent to `String.format`) or `+`. (String Templates were explored as a preview feature and later withdrawn, so do not rely on them.) 6. **Literal triple-quotes.** To include `"""` inside the block, escape at least one quote (`\"""`) so it is not read as the closing delimiter. ## Editor/formatter risk Auto-formatters and IDEs may re-indent text-block content; if the closing delimiter or content shifts, the *value* changes. Lock formatter settings for text blocks and prefer values that do not depend on fragile alignment when correctness matters. ## Bottom line Text blocks are 100% interchangeable with regular String literals at the type/constant level; every "gotcha" is about the compile-time *content* algorithm (opening-line rule, whitespace stripping, trailing newline, tabs/spaces) and the absence of interpolation.

  • Can a text block be used as a switch case label?
    Yes. It is a compile-time constant String, so it is valid anywhere a constant string expression is required, including case labels and annotation element values.
  • How do you insert dynamic values into a text block?
    There is no built-in interpolation. Use the formatted(...) instance method (equivalent to String.format) with placeholders, or concatenate with +. String Templates were a withdrawn preview, so don't rely on them.
  • Why might a == comparison between a text block and a regular literal be true?
    Both are compile-time constant Strings that get interned into the shared string pool, so equal text resolves to the same reference.

saying these in an interview costs you the question

  • Saying text blocks support ${...} interpolation
  • Claiming they cannot be used as case labels or annotation values
  • Asserting they are a different runtime type than String
  • Assuming what you see in source is exactly the resulting value

context

resolving links…