Strings, StringBuilder, Text Blocks and Time

Almost every program handles text and time: names, messages, log lines, JSON, order dates, deadlines. Two things go wrong again and again. First, text handling that is slow or subtly incorrect (comparing with ==, building huge strings in a loop, assuming that length means characters). Second, dates handled with old, error-prone classes. This article fixes both.

• What immutability means for String, and what the string pool is.
• How to build and compare strings efficiently and correctly.
• Why StringBuilder exists, and how it relates to StringBuffer.
• How Unicode complicates "length".
• Text blocks and formatting.
• The java.time API, and how to make time-dependent code testable.

A String object can never change. The Java documentation says it directly: strings are constant, their values cannot be changed after creation, and because they are immutable they can be shared. Methods that look like modifications return a new string and leave the original untouched.

// File: Main.javapublic class Main {    public static void main(String[] args) {        String name = "  Asha Rao  ";        String trimmed = name.strip();        String upper = trimmed.toUpperCase();        name.replace("Asha", "Meena");          // result thrown away!        System.out.println("[" + name + "]");        System.out.println("[" + trimmed + "]");        System.out.println("[" + upper + "]");        String s = "banana";        System.out.println(s.length() + " " + s.charAt(2) + " " + s.indexOf("nan") + " " + s.substring(1, 4));        System.out.println(s.contains("ana") + " " + s.startsWith("ban") + " " + s.replace('a', 'o'));        System.out.println(String.join("-", "2026", "10", "05"));        System.out.println("ab".repeat(3) + " " + "   ".isBlank() + " " + "".isEmpty());        System.out.println("a,b,,c".split(",").length);        System.out.println("Java".equalsIgnoreCase("jAVA") + " " + "apple".compareTo("banana"));    }}

[  Asha Rao  ][Asha Rao][ASHA RAO]6 n 2 anatrue true bonono2026-10-05ababab true true4true -1

The line name.replace("Asha", "Meena"); is the classic beginner bug: the new string is returned and then ignored, so name is unchanged. You must assign the result: name = name.replace(...). The rest of the output shows the common methods. Note that split(",") on "a,b,,c" gives four parts including an empty one. Also remember compareTo returns a negative number, zero or a positive number, and the sign is what matters, not the exact value.

The designers made String immutable for good reasons:

• Safe sharing. Nobody can change a string that another part of the program is using.
• Safe keys. A string's hash code never changes, so it is safe as a HashMap key (as article 7 required), and it can be cached.
• Security. Strings hold file names, URLs and credentials, and checking a string and then using it must not allow it to change in between.
• Thread safety. Immutable objects can be shared between threads freely.
• The string pool. Because strings cannot change, identical literals can be shared.

When the compiler sees the same string literal in several places, the JVM can keep one object and let all of them refer to it. This shared area is called the string pool (or intern pool). The String documentation describes intern() as returning a canonical representation, so equal strings in the pool are the same object.

// File: Main.javapublic class Main {    public static void main(String[] args) {        String a = "hello";        String b = "hello";                       // same literal: shared object        String c = new String("hello");           // forces a separate object        String d = c.intern();                    // asks for the pooled one        System.out.println(a == b);        System.out.println(a == c);        System.out.println(a.equals(c));        System.out.println(a == d);        String part = "hel";        String built = part + "lo";               // computed at runtime        System.out.println(a == built);        System.out.println(a.equals(built));    }}

truefalsetruetruefalsetrue

Literals with the same text are the same object, while new String(...) and strings computed at runtime are separate objects, which is why == gives answers that look random to beginners. The takeaway for real code is: always compare strings with equals (or equalsIgnoreCase). The pool is an implementation optimisation, and in interviews the correct answer to "what is the string pool?" is that it is an area where the JVM keeps one copy of each distinct literal (and interned string), which is possible because strings are immutable. You rarely need intern() yourself.

Because strings are immutable, "appending" creates a new string every time. A single expression like "Hello, " + name + "!" is fine: the compiler turns it into efficient code. (The documentation notes that the way concatenation is implemented is up to the compiler and may differ between JDK versions.) The problem is repeated concatenation in a loop:

String result = "";for (int i = 0; i < 10_000; i++) {    result += i + ",";       // each pass copies the whole string so far}

Each pass copies everything built so far into a new string, so the total work grows with the square of the length. The standard solution is StringBuilder, a mutable sequence of characters you can append to cheaply.

// File: Main.javaimport java.util.List;import java.util.StringJoiner;public class Main {    public static void main(String[] args) {        StringBuilder sb = new StringBuilder();        for (int i = 1; i <= 5; i++) {            sb.append(i).append(',');        }        sb.setLength(sb.length() - 1);          // remove the trailing comma        System.out.println(sb);        System.out.println(sb.reverse());        StringBuilder editor = new StringBuilder("Hello World");        editor.insert(5, ",").replace(7, 12, "Java").append('!');        System.out.println(editor);        StringJoiner joiner = new StringJoiner(", ", "[", "]");        joiner.add("a").add("b").add("c");        System.out.println(joiner);        System.out.println(String.join(" | ", List.of("x", "y", "z")));    }}

1,2,3,4,55,4,3,2,1Hello, Java![a, b, c]x | y | z

When joining a list of items with a separator, prefer String.join, StringJoiner or the stream collector Collectors.joining (article 16), because they remove the "trailing comma" problem.

StringBuilder or StringBuffer? The two classes have the same methods. StringBuffer is the older class from Java 1.0, and all its methods are synchronized, which makes it safe to share between threads but slower. StringBuilder, added in Java 5, is the same without synchronisation. Because you almost never share a half-built string between threads, use StringBuilder. You will see StringBuffer in older code and in interviews. That is its main legacy value.

Java strings use UTF-16. The documentation explains that supplementary characters are represented by surrogate pairs, and index values refer to char code units, so a supplementary character uses two positions. For ordinary English text, one char is one character. For emoji and many other scripts, it is not.

// File: Main.javapublic class Main {    public static void main(String[] args) {        String text = "A" + new StringBuilder().appendCodePoint(0x1F600) + "B";   // A, a smiling face, B        System.out.println(text.length());                          // UTF-16 code units        System.out.println(text.codePointCount(0, text.length()));  // user-visible code points        System.out.println(Character.isSurrogate(text.charAt(1)));        text.codePoints().forEach(cp -> System.out.print(Integer.toHexString(cp) + " "));        System.out.println();    }}

43true41 1f600 42

The string has three characters to a reader but a length() of 4, because the emoji takes two UTF-16 units. If you reverse such a string with charAt you split the pair and produce garbage. Code that handles names, messages or any user-entered text should use the code point methods (codePointAt, codePoints) when it counts or slices. Even code points are not always what users see as one "letter" (some visible characters combine several), which is why serious text handling uses libraries, but the first step is simply to know that length() counts code units.

Embedding multi-line text (SQL, JSON, HTML) in a Java string used to mean a clutter of \n and +. Text blocks, final in Java 15, fix that. JEP 378 describes them as multi-line literals, delimited by triple quotes, that avoid most escape sequences and are formatted in a predictable way, with incidental whitespace (the indentation that only exists to line up your source code) stripped.

// File: Main.javapublic class Main {    public static void main(String[] args) {        String sql = """                SELECT id, company                FROM job_application                WHERE status = 'APPLIED'                ORDER BY applied_on DESC                """;        System.out.print(sql);        String template = """                Dear %s,                your application for %s was received.""";        System.out.println(template.formatted("Asha", "Backend Developer"));        System.out.println(String.format("%-10s|%5d|%8.2f|", "item", 42, 3.14159));    }}

SELECT id, companyFROM job_applicationWHERE status = 'APPLIED'ORDER BY applied_on DESCDear Asha,your application for Backend Developer was received.item      |   42|    3.14|

The compiler removes the indentation common to all lines (here, the position of the closing delimiter and the left-most text decide how much), so the string starts at the left margin. A closing """ on its own line adds a final newline, and placing it at the end of the last line (as in template) does not. formatted(...) (Java 15) and String.format(...) fill placeholders: %s for text, %d for whole numbers, %f for decimals, %n for a line break, with width and precision options. One caution: number formatting depends on the locale. In some locales String.format("%.2f", 3.5) prints 3,50, and for machine-readable output you should pass Locale.ROOT or Locale.US explicitly: String.format(Locale.ROOT, "%.2f", value).

A pitfall with split: its argument is a regular expression, so "1.2.3".split(".") returns an empty array (a dot matches any character), and you must write split("\\.").

Dates and times look simple and are famously hard: time zones, daylight saving time, leap years, different calendars. For years Java's java.util.Date and Calendar were the tools, and they had design flaws: they were mutable, Calendar months started at zero, SimpleDateFormat was not thread-safe, and Date mixed a point in time with a calendar view. Java 8 introduced the java.time package (based on the ISO-8601 calendar), and its classes are all immutable and thread-safe, as the package documentation states. Use java.time for all new code, and treat Date and Calendar as legacy that you must be able to read.

The key is to choose the class that matches the idea:

// File: Main.javaimport java.time.DayOfWeek;import java.time.Duration;import java.time.Instant;import java.time.LocalDate;import java.time.Period;import java.time.ZoneId;import java.time.ZonedDateTime;import java.time.format.DateTimeFormatter;import java.time.temporal.ChronoUnit;public class Main {    public static void main(String[] args) {        LocalDate applied = LocalDate.of(2026, 10, 5);        LocalDate followUp = applied.plusDays(14);        System.out.println(followUp + " is a " + followUp.getDayOfWeek());        System.out.println(applied.isBefore(followUp) + " " + applied.getDayOfWeek().equals(DayOfWeek.MONDAY));        System.out.println(ChronoUnit.DAYS.between(applied, LocalDate.of(2026, 12, 25)) + " days to Christmas");        Period age = Period.between(LocalDate.of(1998, 3, 15), applied);        System.out.println(age.getYears() + " years, " + age.getMonths() + " months");        LocalDate parsed = LocalDate.parse("2026-02-28").plusDays(1);   // ISO format parses directly        System.out.println(parsed + " " + LocalDate.of(2024, 2, 28).plusDays(1));        DateTimeFormatter indian = DateTimeFormatter.ofPattern("dd/MM/yyyy");        System.out.println(applied.format(indian) + " " + LocalDate.parse("25/12/2026", indian));        Instant start = Instant.parse("2026-10-05T08:00:00Z");        Instant end = Instant.parse("2026-10-05T09:45:30Z");        Duration elapsed = Duration.between(start, end);        System.out.println(elapsed + " = " + elapsed.toMinutes() + " minutes");        ZonedDateTime inMumbai = start.atZone(ZoneId.of("Asia/Kolkata"));        ZonedDateTime inLondon = start.atZone(ZoneId.of("Europe/London"));        System.out.println(inMumbai.toLocalTime() + " in Mumbai, " + inLondon.toLocalTime() + " in London");    }}

2026-10-19 is a MONDAYtrue true81 days to Christmas28 years, 6 months2026-03-01 2024-02-2905/10/2026 2026-12-25PT1H45M30S = 105 minutes13:30 in Mumbai, 09:00 in London

Notice several design points. Every "change" (plusDays) returns a new object. Dates parse and print in the standard ISO format (2026-10-05), and you provide a DateTimeFormatter for other formats. LocalDate handles leap years (the 2024 result differs from 2026). A Period measures human calendar differences, and a Duration measures exact elapsed time. And one Instant becomes different local times in different zones.

1. Store and exchange timestamps as Instant (UTC), and convert to a zone only when displaying to people. Store a plain date (a birthday, a due date) as a LocalDate, because it has no time zone.
2. Never subtract dates yourself with arithmetic. Use ChronoUnit, Period or Duration.
3. Be explicit about the zone. ZoneId.systemDefault() varies between machines, and code that depends on it behaves differently on a server and on your laptop.
4. Do not use LocalDateTime for a moment in time, because it cannot tell you which instant it is without a zone.

Code that calls LocalDate.now() directly gives a different answer every day, which makes it impossible to test deterministically. The java.time.Clock class provides the current time, and you can pass one in. This is the composition idea from article 6 applied to time.

// File: Main.javaimport java.time.Clock;import java.time.Instant;import java.time.LocalDate;import java.time.ZoneOffset;public class Main {    static class ReminderService {        private final Clock clock;        ReminderService(Clock clock) {            this.clock = clock;        }        boolean isOverdue(LocalDate dueDate) {            return LocalDate.now(clock).isAfter(dueDate);        }    }    public static void main(String[] args) {        Clock fixed = Clock.fixed(Instant.parse("2026-10-05T10:00:00Z"), ZoneOffset.UTC);        ReminderService service = new ReminderService(fixed);        System.out.println(service.isOverdue(LocalDate.of(2026, 10, 4)));        System.out.println(service.isOverdue(LocalDate.of(2026, 10, 5)));        System.out.println(service.isOverdue(LocalDate.of(2026, 10, 6)));    }}

truefalsefalse

In production you pass Clock.systemUTC() (or a system clock for a specific zone). In a test you pass a fixed clock, and the test gives the same answer every day. We use exactly this technique in the Spring Boot project (article 33).

• Comparing strings with ==.
• Ignoring the return value of replace, trim, toUpperCase and other methods.
• Concatenating in a loop instead of using StringBuilder.
• Assuming length() equals the number of visible characters.
• Using split with a special character such as . or | without escaping.
• Formatting numbers without a locale when the output must be machine-readable.
• Using Date, Calendar or SimpleDateFormat in new code.
• Calling now() everywhere, which makes code untestable.
• Using LocalDateTime for timestamps instead of Instant.

static String joinWords(List<String> words) {    StringBuilder sb = new StringBuilder();    for (String word : words) {        if (sb.length() > 0) {            sb.append(' ');        }        sb.append(word);    }    return sb.toString();}

static int codePointCount(String text) {    return text.codePointCount(0, text.length());}

LocalDate start = LocalDate.of(2026, 10, 5);long days = ChronoUnit.DAYS.between(start, LocalDate.of(2027, 3, 31));   // 177LocalDate later = start.plusDays(90);                                       // 2027-01-03

class WeekendChecker {    private final Clock clock;    WeekendChecker(Clock clock) {        this.clock = clock;    }    boolean isWeekend() {        return LocalDate.now(clock).getDayOfWeek().getValue() >= 6;    }}

• Next: Enums, Records and Sealed Types shows how to model fixed sets of values and data precisely.
• For text from and to files: File I/O and Serialization.
• For immutable values in maps: Maps and How HashMap Works.