Forem: 9mac-dev

Java 17 Features Every Senior Developer Should Know - Part 6: Complete Reference Guide & Syntax Cheat Sheet

9mac-dev — Wed, 19 Nov 2025 20:46:26 +0000

Part 6 of 6 | The final installment in our comprehensive Java 17 features series

This is Part 6 (final) of "Java 17 Features Every Senior Developer Should Know" - your complete desktop reference for all 6 modern Java features spanning Java 10-17. This guide consolidates everything from Parts 1-5, providing syntax cards, decision matrices, and real-world patterns you can reference while working with contemporary Java code.

Complete Series Overview

We've covered 6 major Java features that fundamentally changed how developers write clean, maintainable code:

Part	Feature	Release	Purpose
1	var - Type Inference	Java 10	Eliminate verbose type declarations
2	Records - Immutable Data	Java 16	Replace boilerplate data classes
3	Sealed Classes - Hierarchy Control	Java 17	Enforce closed type systems
4	Pattern Matching - Type Safety	Java 16	Atomic type checking + binding
5	Switch Expressions - Value Returns	Java 14	Modern conditional logic
6	Text Blocks - Multi-line Strings	Java 15	No escape sequence hell

Why This Matters

Modern Java (10-17) brought three transformative principles:

1. Less Boilerplate

Before Java 16, creating a simple data class meant 30+ lines of repetitive code. Today:

// Java 8
public final class Point {
    private final int x;
    private final int y;

    public Point(int x, int y) {
        this.x = x;
        this.y = y;
    }

    public int getX() { return x; }
    public int getY() { return y; }

    @Override
    public boolean equals(Object obj) { /* ... */ }

    @Override
    public int hashCode() { /* ... */ }

    @Override
    public String toString() { /* ... */ }
}

// Java 17
record Point(int x, int y) {}

2. More Safety

The compiler now catches entire categories of errors at compile-time:

// Sealed classes + pattern matching = exhaustive checking
sealed interface Result permits Success, Failure {}

String msg = switch (result) {
    case Success(var val) -> "Got: " + val;
    case Failure(var err) -> "Error: " + err;
    // Compiler ensures all cases covered!
};

3. Better Readability

Code now expresses intent directly:

// Multi-line strings without escape sequences
var query = """
    SELECT u.name, u.email, COUNT(o.id) as order_count
    FROM users u
    LEFT JOIN orders o ON u.id = o.user_id
    WHERE o.status = 'COMPLETED'
    GROUP BY u.name, u.email
    ORDER BY order_count DESC""";

Quick Reference: All 6 Features at a Glance

var Keyword (Java 10) - Type Inference

When: Type is obvious from the right side

var message = "Hello";                          // Clear ✅
var count = 42;                                 // Clear ✅
var users = List.of("Alice", "Bob");           // Clear ✅
var map = new HashMap<String, Integer>();      // Clear ✅
var data = fetchData();                         // Unclear ❌

Key insight: Compile-time inference only - not dynamic typing. Local variables only.

Records (Java 16) - Immutable Data Carriers

When: Creating immutable data structures (DTOs, value objects, configuration)

// Basic record
record Person(String name, int age) {}

// With validation
record Range(int start, int end) {
    public Range {
        if (start > end) {
            throw new IllegalArgumentException("Invalid range");
        }
    }
}

// With methods
record User(String email, int age) {
    public User {
        email = email.toLowerCase(); // Normalization
    }

    public boolean isAdult() {
        return age >= 18;
    }

    public User withAge(int newAge) {
        return new User(email, newAge);
    }
}

// Generic records
record Pair<T, U>(T first, U second) {
    public Pair<U, T> swap() {
        return new Pair<>(second, first);
    }
}

// Implementing interfaces
sealed interface Shape permits Circle, Rectangle {}

record Circle(double radius) implements Shape {
    public double area() { return Math.PI * radius * radius; }
}

record Rectangle(double width, double height) implements Shape {
    public double area() { return width * height; }
}

Automatic: constructor, accessors (x() not getX()), equals(), hashCode(), toString()

Key insight: Immutable by default. One line replaces 30+ lines of boilerplate.

Sealed Classes (Java 17) - Controlled Inheritance

When: You need a closed type hierarchy with known subtypes

// Fixed alternatives
sealed interface Payment permits CreditCard, PayPal, BankTransfer {}

record CreditCard(String number, String expiry) implements Payment {}
record PayPal(String email) implements Payment {}
record BankTransfer(String accountNumber) implements Payment {}

// With extension point
sealed interface PaymentExtension permits CreditCard, PayPal, CustomPayment {}
non-sealed interface CustomPayment extends PaymentExtension {} // Open for extension

// Class hierarchy
sealed class Result<T> permits Success, Failure {}

final class Success<T> extends Result<T> {
    private final T value;

    public Success(T value) { this.value = value; }
    public T getValue() { return value; }
}

final class Failure<T> extends Result<T> {
    private final String error;

    public Failure(String error) { this.error = error; }
    public String getError() { return error; }
}

Subtypes must be: final, sealed, or non-sealed

Key insight: Compiler knows all subtypes - enables exhaustive pattern matching without default cases.

Pattern Matching (Java 16) - Type Check + Cast

When: Type checking with immediate variable use

// Basic pattern matching
if (obj instanceof String s) {
    System.out.println(s.toUpperCase());
}

// With guards
if (obj instanceof String s && s.length() > 0) {
    return s.toUpperCase();
}

// Simplified equals()
@Override
public boolean equals(Object obj) {
    return obj instanceof Point p
        && this.x == p.x
        && this.y == p.y;
}

// Polymorphic dispatch
if (shape instanceof Circle c) {
    return Math.PI * c.radius() * c.radius();
} else if (shape instanceof Rectangle r) {
    return r.width() * r.height();
}

// Type hierarchies with pattern matching in switch
double area = switch (shape) {
    case Circle(var r) -> Math.PI * r * r;
    case Rectangle(var w, var h) -> w * h;
    case Triangle(var b, var h) -> (b * h) / 2.0;
};

Scope rules: Variables are scoped by flow analysis:

if (obj instanceof String s && s.length() > 5) {
    // 's' in scope here
}

if (!(obj instanceof String s)) {
    // 's' NOT in scope
} else {
    // 's' IS in scope here
}

Key insight: Eliminates manual casting. Combines type check + cast + assignment in one atomic operation.

Switch Expressions (Java 14) - Value-Returning Switch

When: Returning values from multiple conditional branches

// Basic switch expression
String dayType = switch (day) {
    case MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY -> "Weekday";
    case SATURDAY, SUNDAY -> "Weekend";
};

// With yield for multi-statement
int result = switch (operation) {
    case ADD -> {
        System.out.println("Adding numbers");
        yield a + b;
    }
    case SUBTRACT -> {
        System.out.println("Subtracting");
        yield a - b;
    }
    case MULTIPLY -> a * b;
    case DIVIDE -> a / b;
    default -> throw new IllegalArgumentException("Unknown operation");
};

// Exhaustive enum matching (no default needed)
int monthDays = switch (month) {
    case JANUARY, MARCH, MAY, JULY, AUGUST, OCTOBER, DECEMBER -> 31;
    case APRIL, JUNE, SEPTEMBER, NOVEMBER -> 30;
    case FEBRUARY -> 28; // Ignoring leap years for simplicity
};

// Combined with sealed types for exhaustiveness
String message = switch (result) {
    case Success(var value) -> "Success: " + value;
    case Failure(var error) -> "Error: " + error;
    // No default needed - compiler verifies all cases!
};

Arrow syntax: -> prevents fall-through (unlike traditional :)

Rules:

Must be exhaustive (all cases covered or default)
Use yield for multi-statement branches
No break needed with arrows

Key insight: Cleaner than if-else chains. Compiler enforces completeness.

Text Blocks (Java 15) - Multi-line Strings

When: Multi-line strings without escape sequence hell

// JSON without escaping quotes
String json = """
    {
      "name": "Alice Johnson",
      "email": "alice@example.com",
      "age": 30,
      "active": true
    }""";

// SQL queries with proper formatting
String sqlQuery = """
    SELECT u.id, u.name, COUNT(o.id) as order_count
    FROM users u
    LEFT JOIN orders o ON u.id = o.user_id
    WHERE u.status = 'ACTIVE'
      AND o.created_at > NOW() - INTERVAL 30 DAY
    GROUP BY u.id, u.name
    HAVING COUNT(o.id) > 5
    ORDER BY order_count DESC""";

// HTML without escaping
String html = """
    <div class="container">
      <h1>Welcome, <span class="user">%s</span></h1>
      <p>Your account balance: <strong>$%.2f</strong></p>
      <a href="/dashboard">View Dashboard</a>
    </div>""".formatted(userName, balance);

// With indentation control
String formatted = """
    Level 1
        Level 2 (indented)
            Level 3 (more indented)
        Back to level 2
    Back to level 1
    """;

// Line continuation (backslash)
String poem = """
    Roses are red, \\
    Violets are blue, \\
    Java 17 features \\
    Make code shine through.""";

// Essential space (survives whitespace stripping)
String codeBlock = """
    function hello() {
        console.log("Hello!");
    }\s
    """;

// XML configuration
String config = """
    <?xml version="1.0" encoding="UTF-8"?>
    <configuration>
      <database>
        <host>localhost</host>
        <port>5432</port>
        <name>myapp</name>
      </database>
      <logging>
        <level>INFO</level>
      </logging>
    </configuration>""";

Special escapes:

\s - Essential space (survives whitespace stripping)
\ - Line continuation (no newline inserted)
Standard escapes: \n, \t, \", \\

Key insight: All line endings normalized to \n. Opening """ must be followed by newline. Closing """ position determines indent stripping.

Real-World Integration Patterns

Pattern 1: Records + var for Clean Data

var users = List.of(
    new User("alice@test.com", 30),
    new User("bob@test.com", 25),
    new User("charlie@test.com", 35)
);

// Process with var inference
for (var user : users) {
    if (user.age() >= 18) {
        processAdult(user);
    }
}

// Stream operations
var activeAdults = users.stream()
    .filter(u -> u.age() >= 18)
    .map(u -> u.email())
    .toList();

Pattern 2: Sealed Classes + Pattern Matching for Type Safety

sealed interface ApiResponse<T> permits SuccessResponse, ErrorResponse {}

record SuccessResponse<T>(int status, T data) implements ApiResponse<T> {}
record ErrorResponse(int status, String message, String code) implements ApiResponse<Object> {}

// Exhaustive pattern matching guaranteed by compiler
public static <T> void handleResponse(ApiResponse<T> response) {
    switch (response) {
        case SuccessResponse(var status, var data) -> {
            System.out.println("Success: " + data);
        }
        case ErrorResponse(var status, var msg, var code) -> {
            System.err.println("Error [" + code + "]: " + msg);
        }
        // No default needed - compiler verifies all cases!
    }
}

Pattern 3: Text Blocks + var for Template Building

var userName = "Alice";
var orderTotal = 149.99;
var orderId = "ORD-2025-001";

var emailTemplate = """
    <html>
      <body>
        <h2>Order Confirmation</h2>
        <p>Hello %s,</p>
        <p>Your order #%s has been confirmed.</p>
        <p><strong>Total: $%.2f</strong></p>
        <p>Thank you for your business!</p>
      </body>
    </html>""".formatted(userName, orderId, orderTotal);

var sqlTemplate = """
    INSERT INTO orders (user_id, total, status, created_at)
    VALUES (?, ?, 'PENDING', NOW())
    RETURNING id, created_at""";

Pattern 4: Complete Domain Model (All Features Combined)

// 1. Sealed hierarchy for domain
sealed interface OrderStatus permits Pending, Processing, Shipped, Delivered, Cancelled {}

record Pending() implements OrderStatus {}
record Processing() implements OrderStatus {}
record Shipped(String trackingNumber) implements OrderStatus {}
record Delivered(LocalDateTime deliveredAt) implements OrderStatus {}
record Cancelled(String reason) implements OrderStatus {}

// 2. Records for data
record OrderItem(String productId, int quantity, BigDecimal price) {}

record Order(
    String id,
    String customerId,
    List<OrderItem> items,
    OrderStatus status,
    LocalDateTime createdAt
) {
    public Order {
        items = List.copyOf(items); // Defensive copy
    }

    public BigDecimal total() {
        return items.stream()
            .map(item -> item.price().multiply(BigDecimal.valueOf(item.quantity())))
            .reduce(BigDecimal.ZERO, BigDecimal::add);
    }
}

// 3. Switch expressions with pattern matching
public static String getStatusMessage(Order order) {
    return switch (order.status()) {
        case Pending() -> "Your order is pending processing";
        case Processing() -> "We're preparing your order";
        case Shipped(var tracking) -> "Shipped! Track: " + tracking;
        case Delivered(var date) -> "Delivered on " + date.format(DateTimeFormatter.ISO_LOCAL_DATE);
        case Cancelled(var reason) -> "Order cancelled: " + reason;
    };
}

// 4. var + text blocks for output
public static void printOrderSummary(Order order) {
    var items = order.items();
    var total = order.total();
    var status = getStatusMessage(order);

    var summary = """
        ==== ORDER SUMMARY ====
        Order ID: %s
        Customer: %s
        Status: %s

        Items (%d):
        %s

        Total: $%.2f

        Created: %s
        """.formatted(
            order.id(),
            order.customerId(),
            status,
            items.size(),
            items.stream()
                .map(item -> "  • %s (qty: %d) @ $%.2f each".formatted(
                    item.productId(), item.quantity(), item.price()))
                .collect(Collectors.joining("\n")),
            total,
            order.createdAt().format(DateTimeFormatter.ISO_LOCAL_DATE_TIME)
        );

    System.out.println(summary);
}

// 5. Usage showing all features together
var order = new Order(
    "ORD-2025-001",
    "CUST-123",
    List.of(
        new OrderItem("PROD-A", 2, new BigDecimal("29.99")),
        new OrderItem("PROD-B", 1, new BigDecimal("49.99"))
    ),
    new Shipped("UPS-123456"),
    LocalDateTime.now().minusDays(2)
);

printOrderSummary(order);

When to Use Each Feature

Use var When:

Type is obvious from right side: var user = new User("Alice", 30)
Long generic types: var map = new HashMap<String, List<Setting>>()
Stream chains: var filtered = list.stream().filter(...).map(...)

Use Records When:

Creating data transfer objects (DTOs)
Modeling immutable value objects
Building configuration objects
Returning multiple values from methods

Use Sealed Classes When:

You have a fixed set of subtypes
Building domain models with known alternatives
Want exhaustive pattern matching without defaults
Controlling API boundaries

Use Pattern Matching When:

Type checking with immediate variable use
Simplifying equals() implementations
Reducing null-check boilerplate
Guard conditions: obj instanceof String s && s.length() > 5

Use Switch Expressions When:

Mapping enum values to results
Returning values from branches (not just statements)
Exhaustive enum/sealed type matching
Complex conditional logic (cleaner than if-else chains)

Use Text Blocks When:

Multi-line JSON, SQL, HTML, or XML
Embedded code snippets in strings
Long error messages
Test fixtures and templates

Decision Matrix

Need	Feature	Why
Reduce type declarations	var	Type inference eliminates noise
Replace boilerplate classes	Records	Automatic equals(), hashCode(), toString()
Enforce type hierarchy	Sealed	Compiler knows all subtypes
Type-safe instanceof	Pattern Matching	One-line type check + cast + bind
Conditional return values	Switch Expressions	Cleaner than if-else chains
Multi-line strings	Text Blocks	No escape sequence nightmares

Key Insights

These features work together: Records + sealed classes enable exhaustive pattern matching. var + records = clean data structures. Text blocks + var = template building.
Backward compatible: Existing Java 8 code still works. Adopt features gradually.
Compiler enforcement: Sealed classes and pattern matching catch entire categories of runtime errors at compile-time.
Less ceremony: Together, these features reduce boilerplate by 50-70% compared to Java 8.
Modern idioms: Understanding these features is essential for reading contemporary Java code.

Full Articles & Examples

For detailed coverage, advanced patterns, and comprehensive examples:

👉 Full Part 6 article: blog.9mac.dev/java-17-features-every-senior-developer-should-know-part-6-syntax-cheat-sheet

Complete Series

Part 1: var Keyword - Type Inference
Part 2: Records - Immutable Data Carriers
Part 3: Sealed Classes - Hierarchy Control
Part 4: Pattern Matching & Switch Expressions
Part 5: Text Blocks - Multi-line Strings
Part 6: Syntax Cheat Sheet & Reference Guide

Run the Examples

All code examples are available in the repository with full test coverage:

git clone https://github.com/dawid-swist/blog-9mac-dev-code.git
cd blog-post-examples/java/2025-10-25-java17-features-every-senior-developer-should-know
../../gradlew test

Run tests for specific features:

./gradlew test --tests "*VarExample*"
./gradlew test --tests "*RecordExample*"
./gradlew test --tests "*SealedExample*"
./gradlew test --tests "*PatternExample*"
./gradlew test --tests "*SwitchExample*"
./gradlew test --tests "*TextBlockExample*"

Series Statistics

Total code examples: 40+ real-world patterns
Test coverage: 100% with BDD-style test names
Reading time: 1-2 hours for complete series
Java versions covered: 10, 14, 15, 16, 17
Features enabled: 6 major language enhancements
Lines of boilerplate eliminated: 50-70%

This concludes the "Java 17 Features Every Senior Developer Should Know" series.

All 6 parts are now published with comprehensive examples, best practices, and real-world patterns you can use immediately in production code.

Java 17 Features Every Senior Developer Should Know - Part 5: Text Blocks

9mac-dev — Wed, 19 Nov 2025 18:00:30 +0000

Part 5 of 6 | For senior Java developers modernizing codebases to Java 17

The Problem Text Blocks Solve

Before Java 15, embedding multi-line strings in Java code was a nightmare of escape sequences, concatenation operators, and unreadable structure. Every JSON fixture, SQL query, or HTML template required extensive reformatting:

// The old way - escape sequence hell
String json = "{\n" +
              "  \"name\": \"Alice\",\n" +
              "  \"age\": 30,\n" +
              "  \"email\": \"alice@example.com\"\n" +
              "}";

String query = "SELECT u.name, u.email, o.total\n" +
               "FROM users u\n" +
               "JOIN orders o ON u.id = o.user_id\n" +
               "WHERE o.status = 'COMPLETED'\n" +
               "ORDER BY o.created_at DESC";

Text blocks eliminate this pain entirely while introducing critical security considerations that every senior developer must understand.

Why This Matters

Readability Crisis: Traditional multi-line strings obscure the actual data structure with Java syntax noise (+, \n, \"), making maintenance difficult and copy-pasting from external tools (Postman, SQL clients) a reformatting burden.

Security Landmines: Text blocks combined with formatted() create powerful template capabilities, but misuse with SQL queries or HTML content introduces SQL injection and XSS vulnerabilities that can compromise production systems.

Maintenance Burden: Every content update requires modifying multiple lines with careful attention to escape sequences and concatenation operators—a recipe for bugs.

What Are Text Blocks?

Text blocks use triple-double-quote delimiters (""") to create multi-line string literals that automatically normalize line terminators, strip common indentation, and eliminate most escape sequences:

// The new way - clean and readable
String json = """
    {
      "name": "Alice",
      "age": 30,
      "email": "alice@example.com"
    }
    """;

String query = """
    SELECT u.name, u.email, o.total
    FROM users u
    JOIN orders o ON u.id = o.user_id
    WHERE o.status = 'COMPLETED'
    ORDER BY o.created_at DESC
    """;

Key benefits:

No escape sequences for quotes or newlines
Natural indentation preserved
Copy-paste friendly from external tools
Zero runtime performance overhead

When to Use Text Blocks

✅ Perfect for:

JSON, XML, HTML structures in test fixtures
SQL queries (especially complex CTEs)
Email templates and invoices
Configuration files and API responses
Any multi-line literal in embedded languages

❌ Avoid for:

Single-line strings (use regular "...")
Platform-specific line endings (text blocks normalize to \n)
Strings requiring immediate complex processing

Real-World Examples

Example 1: JSON Test Fixtures

public static String getUserJSONFormatted(String name, int age, String email) {
    return """
        {
          "name": "%s",
          "age": %d,
          "email": "%s"
        }""".formatted(name, age, email);
}

// Usage
String json = getUserJSONFormatted("Charlie", 25, "charlie@example.com");

Output:

{
  "name": "Charlie",
  "age": 25,
  "email": "charlie@example.com"
}

Example 2: HTML Templates Without Escape Hell

public static String getDashboardHTML() {
    return """
        <html>
          <head>
            <title>User Dashboard</title>
          </head>
          <body>
            <h1>Welcome, User!</h1>
            <p>This is your dashboard.</p>
          </body>
        </html>""";
}

No more escaping quotes! The structure is immediately clear, matching exactly what you'd see in design tools.

Example 3: Email Template System

public static String renderEmailTemplate(String recipientName, String activationUrl, String expirationHours) {
    return """
        <html>
          <body style="font-family: Arial, sans-serif;">
            <h2>Welcome, %s!</h2>
            <p>Thank you for signing up. Please activate your account within %s hours.</p>
            <p><a href="%s" style="background-color: #007bff; color: white; padding: 10px 20px;">Activate Account</a></p>
            <p>Best regards,<br>The Team</p>
          </body>
        </html>""".formatted(recipientName, expirationHours, activationUrl);
}

Text blocks combined with formatted() create lightweight template systems without external dependencies—perfect for emails, invoices, and configurations.

Example 4: Complex SQL with CTEs

public static String getTopCustomersQuerySafe() {
    return """
        WITH customer_totals AS (
            SELECT u.id, u.name, u.email,
                   SUM(o.total) as total_spent,
                   COUNT(o.order_id) as order_count
            FROM users u
            JOIN orders o ON u.id = o.user_id
            WHERE o.status = ?
              AND o.created_at >= ?
            GROUP BY u.id, u.name, u.email
        )
        SELECT id, name, email, total_spent, order_count
        FROM customer_totals
        WHERE total_spent >= ?
        ORDER BY total_spent DESC
        LIMIT ?""";
}

Notice the ? placeholders—this demonstrates the secure pattern for SQL with text blocks.

Security Considerations (CRITICAL)

SQL Injection - The Danger Zone

NEVER use formatted() with SQL queries and user input:

// ❌ DANGEROUS - SQL Injection Vulnerability!
String status = userInput;  // User enters: "COMPLETED' OR '1'='1"
String sql = """
    SELECT * FROM orders
    WHERE status = '%s'
    """.formatted(status);
// Resulting SQL: SELECT * FROM orders WHERE status = 'COMPLETED' OR '1'='1'
// This returns ALL orders, bypassing security!

Worse attacks can delete entire tables:

// ❌ If user enters: "'; DROP TABLE orders; --"
String sql = """
    SELECT * FROM orders WHERE status = '%s'
    """.formatted(maliciousInput);
// Your entire orders table is DELETED!

The Safe SQL Pattern

Always use PreparedStatement with text blocks:

// ✅ SAFE - PreparedStatement prevents SQL injection
String query = """
    SELECT * FROM orders
    WHERE status = ?
      AND total >= ?
    """;

try (PreparedStatement ps = connection.prepareStatement(query)) {
    ps.setString(1, userInput);  // Automatically escaped - safe!
    ps.setDouble(2, minAmount);
    try (ResultSet rs = ps.executeQuery()) {
        // Process results
    }
}

Key points:

Text blocks improve SQL readability
PreparedStatement prevents injection
Use ? placeholders, NOT %s formatting
Set parameters via setString(), setInt(), setDouble(), etc.

XSS Injection - HTML Security

NEVER use formatted() with HTML and user input without escaping:

// ❌ DANGEROUS - XSS Vulnerability
String username = userInput;  // User enters: "<script>alert('XSS')</script>"
String html = """
    <html>
      <body>
        <h1>Welcome, %s!</h1>
      </body>
    </html>""".formatted(username);
// The script executes in the browser, potentially stealing cookies!

Always escape HTML entities:

// ✅ SAFE - Escape HTML before formatting
public static String escapeHtml(String input) {
    return input
        .replace("&", "&amp;")
        .replace("<", "&lt;")
        .replace(">", "&gt;")
        .replace("\"", "&quot;")
        .replace("'", "&#x27;");
}

String username = escapeHtml(userInput);
String html = """
    <html>
      <body>
        <h1>Welcome, %s!</h1>
      </body>
    </html>""".formatted(username);

Advanced Patterns

Indentation Rules

The closing """ delimiter determines indentation stripping:

// Closing delimiter indented - strips that amount
String indented = """
    Hello
    World
    """;
// Content: "Hello\nWorld\n" (4 spaces stripped from each line)

// Closing delimiter aligned left - minimal stripping
String leftAligned = """
    Hello
    World
""";
// Content: "    Hello\n    World\n" (preserves indentation)

Essential Space and Line Continuation

Two new escape sequences provide fine-grained control:

// \s preserves trailing whitespace
String essential = """
    Line with trailing space:\s
    Another line
    """;

// \ continues lines without newline
String continued = """
    This is a very long sentence that we want to \
    split in source code but keep as \
    one line in the string.
    """;

Relative Indentation Preserved

String structured = """
    Level 1
        Level 2
            Level 3
        Level 2
    Level 1
    """;

Text blocks preserve relative indentation while stripping common leading whitespace—perfect for code examples and structured data.

Key Insight

Text blocks eliminate the impedance mismatch between Java code and embedded languages (JSON, SQL, HTML), making maintenance dramatically easier. However, they are a readability feature, NOT a security feature—always use PreparedStatement for SQL and escape HTML entities for web content.

Read the Full Article

The complete guide includes:

8 comprehensive examples with full code and detailed output
Security deep-dive covering SQL injection and XSS prevention patterns
Indentation edge cases and sophisticated formatting rules
Template system patterns for emails, invoices, and configurations
Performance analysis demonstrating zero runtime overhead
Text blocks vs template engines decision framework
Complete implementation checklist for migrating existing code
Common mistakes and how to avoid them

Clone the repository and run examples:

git clone https://github.com/dawid-swist/blog-9mac-dev-code.git
cd blog-post-examples/java/2025-10-25-java17-features-every-senior-developer-should-know
../../gradlew test --tests *part5*

All 8 examples include complete test coverage demonstrating secure and unsafe patterns.

Series Navigation:

Part 1 - Introduction & var Keyword
Part 2 - Records
Part 3 - Sealed Classes
Part 4 - Pattern Matching & Switch Expressions
Part 5 - Text Blocks (you are here)
Part 6 - Syntax Cheat Sheet

Java 17 Features - Part 4: Pattern Matching & Switch Expressions

9mac-dev — Sun, 16 Nov 2025 19:42:18 +0000

This is a teaser article. Pattern matching represents Java's first serious steps toward a programming paradigm that functional languages have enjoyed for decades. Combined with switch expressions, these features fundamentally transform how you write conditional logic and type checks. This article explores pattern matching for instanceof, switch expressions, guarded patterns, record destructuring, and how sealed types guarantee exhaustiveness.

Why This Matters

For decades, Java developers have suffered through the "instanceof-cast ceremony":

// The old pain point - Java 8
if (obj instanceof String) {
    String s = (String) obj;
    return "String: " + s.length();
} else if (obj instanceof Integer) {
    Integer i = (Integer) obj;
    return "Integer: " + i;
}

Pattern matching collapses this:

// Java 16+ - Pattern matching
if (obj instanceof String s) {
    return "String: " + s.length();
} else if (obj instanceof Integer i) {
    return "Integer: " + i;
}

Java 17 brings these together: pattern matching + switch expressions create powerful, type-safe conditional logic.

What is Pattern Matching?

Pattern matching is structural decomposition combined with conditional dispatch. You're asking:

"What shape is this data?"
"If it matches, bind the components to names I can use"

Type Patterns (Java 16+)

if (obj instanceof String s) {
    System.out.println(s.length());
}

Guarded Patterns (Java 16+)

if (obj instanceof String s && s.length() > 5) {
    return s.toUpperCase();
}

Pattern Matching in Switch (Java 17+)

String result = switch (obj) {
    case String s -> "String: " + s;
    case Integer i -> "Integer: " + i;
    case null -> "Null";
    default -> "Unknown";
};

Real-World Example 1: equals() Implementation

Before Java 16:

@Override
public boolean equals(Object obj) {
    if (this == obj) return true;
    if (obj == null) return false;
    if (getClass() != obj.getClass()) return false;
    Point other = (Point) obj;
    return this.x == other.x && this.y == other.y;
}

Java 16+ with pattern matching:

@Override
public boolean equals(Object obj) {
    return obj instanceof Point p &&
           this.x == p.x && this.y == p.y;
}

Real-World Example 2: Switch Expressions

Before Java 14:

String dayType;
switch (day) {
    case MONDAY: case TUESDAY: case WEDNESDAY:
    case THURSDAY: case FRIDAY:
        dayType = "Weekday";
        break;
    case SATURDAY: case SUNDAY:
        dayType = "Weekend";
        break;
}

Java 14+ with arrow syntax:

String dayType = switch (day) {
    case MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY -> "Weekday";
    case SATURDAY, SUNDAY -> "Weekend";
};

Real-World Example 3: Pattern Matching with Sealed Types

sealed interface Shape permits Circle, Rectangle, Triangle {}
record Circle(double radius) implements Shape {}
record Rectangle(double width, double height) implements Shape {}
record Triangle(double base, double height) implements Shape {}

int area = switch (shape) {
    case Circle c -> (int) (Math.PI * c.radius() * c.radius());
    case Rectangle r -> r.width() * r.height();
    case Triangle t -> (t.base() * t.height()) / 2;
};

Real-World Example 4: Guarded Patterns

String classify = switch (obj) {
    case String s when s.isEmpty() -> "Empty string";
    case String s when s.length() < 5 -> "Short string: " + s;
    case String s -> "Long string: " + s;
    default -> "Not a string";
};

Real-World Example 5: Result Pattern

sealed interface Result<T> permits Success, Failure {}
record Success<T>(T value) implements Result<T> {}
record Failure<T>(String error) implements Result<T> {}

public static <T> String describe(Result<T> result) {
    return switch (result) {
        case Success<T> s -> "Success: " + s.value();
        case Failure<T> f -> "Failure: " + f.error();
    };
}

Key Insight

Pattern matching represents a paradigm shift toward declarative conditional logic. Combined with sealed types, the compiler enforces exhaustiveness at compile-time, preventing entire classes of runtime type errors.

Read the Full Article

Discover more about pattern matching and switch expressions:

Type patterns and scope rules
Switch expressions vs traditional switch
Guarded patterns with when clause
Record destructuring in patterns
Sealed types with exhaustiveness checking
Best practices and migration strategy

Full article: https://blog.9mac.dev/java-17-features-every-senior-developer-should-know-part-4-pattern-matching-and-switch-expressions

Clone and Run

git clone https://github.com/dawid-swist/blog-9mac-dev-code.git
cd blog-post-examples/java/2025-10-25-java17-features-every-senior-developer-should-know
../../gradlew test --tests *part4*

Part of the "Java 17 Features Every Senior Developer Should Know" series

Part 1: var Keyword
Part 2: Records
Part 3: Sealed Classes
Part 4: Pattern Matching & Switch (You are here)
Part 5: Text Blocks
Part 6: Syntax Cheat Sheet

Java #Java17 #PatternMatching #SwitchExpressions #Programming

Java 17 Features Every Senior Developer Should Know - Part 3: Sealed Classes

9mac-dev — Tue, 11 Nov 2025 20:01:32 +0000

Part 3 of 6 - Essential Java 17+ features for senior developers upgrading from Java 8, 11, or 13.

Sealed classes give you the middle ground between final (too restrictive) and open (too permissive), enabling compiler-verified exhaustive checking. This article explores controlled inheritance, the three modifiers, and patterns for building maintainable type hierarchies.

Why This Matters

Imagine a payment processing system. You design an abstract Payment class for credit cards, debit cards, and cash. A year later, another team adds CryptoPayment without telling you. Now your switch statement that handles all payment types doesn't—and you have a bug in production that the compiler never caught.

The problem: Java forces a false choice between final (too restrictive) and open (too permissive). You can't say "extend this class, but ONLY in these specific ways."

Sealed classes (Java 17) solve this: fine-grained control over which classes can extend yours, with compiler-enforced completeness checking.

What are Sealed Classes?

A sealed class restricts which other classes can extend it. You explicitly list the permitted subclasses using the permits clause:

public sealed abstract class Payment
    permits CreditCard, DebitCard, Cash {
    public abstract void process();
}

public final class CreditCard extends Payment { }
public final class DebitCard extends Payment { }
public final class Cash extends Payment { }

// This won't compile - CryptoPayment not in permits list
// public class CryptoPayment extends Payment { }

Exhaustive Pattern Matching

Sealed classes with pattern matching eliminate the need for default cases:

return switch (payment) {
    case CreditCard cc -> "Card: " + cc.cardNumber();
    case DebitCard dc -> "Debit: " + dc.accountNumber();
    case Cash cash -> "Cash: " + cash.amount();
    // Compiler verifies all cases covered!
};

Add a new implementation? The compiler forces you to update all switch statements.

Key Insight

Sealed classes give you the middle ground between final (no extensions) and open (unlimited extensions). They enable the compiler to verify completeness, preventing bugs and making refactoring safer.

The Three Modifiers

1. `sealed` - Parent classes/interfaces that restrict extensions

public sealed abstract class Shape
    permits Circle, Rectangle, Triangle {
    abstract double area();
}

2. `final` - Permitted subclasses that can't be extended further

public final class Circle extends Shape {
    private double radius;

    @Override
    double area() { return Math.PI * radius * radius; }
}

3. `non-sealed` - Permitted subclass that can be extended by anyone

public non-sealed class SpecialShape extends Shape {
    // Any class can now extend SpecialShape
    @Override
    double area() { return 0; }
}

Real-World Example: Expression Evaluator

public sealed interface Expr
    permits Expr.Num, Expr.Add, Expr.Sub {

    int evaluate();

    record Num(int value) implements Expr {
        public int evaluate() { return value; }
    }

    record Add(Expr left, Expr right) implements Expr {
        public int evaluate() { return left.evaluate() + right.evaluate(); }
    }

    record Sub(Expr left, Expr right) implements Expr {
        public int evaluate() { return left.evaluate() - right.evaluate(); }
    }
}

// Usage with exhaustive pattern matching:
public class EvalExample {
    public static int eval(Expr expr) {
        return switch (expr) {
            case Expr.Num num -> num.value();
            case Expr.Add add -> add.left().evaluate() + add.right().evaluate();
            case Expr.Sub sub -> sub.left().evaluate() - sub.right().evaluate();
            // No default needed - compiler verifies all cases!
        };
    }
}

Common Patterns

Single Level Hierarchy

public sealed abstract class Transport
    permits Car, Bus, Train {}

Multi-Level Hierarchy

public sealed class Vehicle permits Car, Truck {}
public final class Car extends Vehicle {}
public non-sealed class Truck extends Vehicle {} // Others can extend Truck

Sealed Interfaces

public sealed interface Repository<T>
    permits JdbcRepository, MongoRepository {}

Benefits

Compiler Verification: Exhaustive switch statements
Intentional Design: Makes class hierarchies explicit
Refactoring Safety: Adding implementations forces updates
Performance: Enables optimizations (narrower type sets)
Documentation: Code clearly shows permitted extensions

Read the Full Article

Discover much more in Part 3: Sealed Classes on blog.9mac.dev:

Design philosophy behind sealed classes
Multi-level sealed hierarchies with practical patterns
The non-sealed modifier in real-world scenarios
Sealed interfaces with complex implementations
5+ comprehensive examples: payments, shapes, vehicles, JSON
Reflection API for runtime introspection
Best practices and common pitfalls

GitHub Repository

All code examples are ready to clone and run:

git clone https://github.com/dawid-swist/blog-9mac-dev-code.git
cd blog-post-examples/java/2025-10-25-java17-features-every-senior-developer-should-know
../../gradlew test

Next in the series: Part 4 - Pattern Matching & Switch Expressions

Java 17 Features Every Senior Developer Should Know - Part 2: Records

9mac-dev — Tue, 11 Nov 2025 19:56:47 +0000

Part 2 of 6 - Essential Java 17+ features for senior developers upgrading from Java 8, 11, or 13.

Records solve the data class problem: automatically generating constructors, equals(), hashCode(), and toString(). This article covers immutable data carriers, validation patterns, and real-world applications from DTOs to domain models.

Why This Matters

For 20+ years, creating a simple data class meant writing the same ceremony over and over: private final fields, constructor, getters, equals(), hashCode(), and toString(). The most common data structure in Java required 30-50 lines of boilerplate.

Other languages solved this decades ago. Scala case classes (2003), Kotlin data classes (2016), even C# record types (2020)—all understood that data carriers should be one line, not thirty.

Java 17 finally brought a native solution: Records.

What are Records?

A record is a special class designed to be an immutable carrier for data. When you declare a record, the compiler automatically generates constructors, accessors, equals(), hashCode(), and toString().

Before Java 16:

public final class Point {
    private final int x;
    private final int y;

    public Point(int x, int y) { this.x = x; this.y = y; }
    public int x() { return x; }
    public int y() { return y; }

    @Override public boolean equals(Object o) { /* 10 lines */ }
    @Override public int hashCode() { return Objects.hash(x, y); }
    @Override public String toString() { return "Point[x=" + x + ", y=" + y + "]"; }
}

After Java 16:

public record Point(int x, int y) {}

That's it. The compiler generates everything.

Simple Example

public record Book(String title, String author, int year) {}

public class RecordExample {
    public static void main(String[] args) {
        var book = new Book("Clean Code", "Robert Martin", 2008);

        System.out.println(book);  // Book[title=Clean Code, author=Robert Martin, year=2008]
        System.out.println("Title: " + book.title());

        var book2 = new Book("Clean Code", "Robert Martin", 2008);
        System.out.println("Equal: " + book.equals(book2));  // true
    }
}

Key Characteristics

Immutable - Fields are private final, no setters
No inheritance - Records are implicitly final
Perfect for - DTOs, value objects, domain entities

Key Insight

Records eliminate boilerplate without sacrificing type safety. They're the native Java solution to what Project Lombok tried to solve. Your code expresses intent: "immutable data carrier."

More Advanced Examples

Generic Records

public record Pair<T>(T first, T second) {}

public class GenericRecordExample {
    public static void main(String[] args) {
        var stringPair = new Pair<>("Alice", "Bob");
        var numberPair = new Pair<>(42, 100);

        System.out.println(stringPair);     // Pair[first=Alice, second=Bob]
        System.out.println(numberPair);     // Pair[first=42, second=100]
    }
}

Records with Custom Constructor (Compact Constructor)

public record Person(String name, int age) {
    // Compact constructor - implicit parameter assignment
    public Person {
        if (age < 0) {
            throw new IllegalArgumentException("Age cannot be negative");
        }
    }
}

Records vs POJOs

Feature	Traditional Class	Record
Lines of code	30-50	1-2
Constructor	Manual	Generated
equals/hashCode	Manual	Generated
toString	Manual	Generated
Immutability	Optional	Guaranteed
Inheritance	Flexible	Limited (final)

Real-World Use Cases

DTOs (Data Transfer Objects) - Perfect for API responses
Value Objects - Immutable domain model objects
Configuration Objects - Simplify config classes
Test Fixtures - Clean test data builders
Tuple-like Types - Type-safe alternatives to Map

Read the Full Article

Discover much more in Part 2: Records on blog.9mac.dev:

Generic records with type parameters
Custom constructors and validation
Sealed record hierarchies
10+ real-world examples
Performance comparison with POJOs
Integration with streams and collections
Serialization considerations

GitHub Repository

All code examples are ready to clone and run:

git clone https://github.com/dawid-swist/blog-9mac-dev-code.git
cd blog-post-examples/java/2025-10-25-java17-features-every-senior-developer-should-know
../../gradlew test

Next in the series: Part 3 - Sealed Classes (controlled inheritance hierarchies)

Java 17 Features Every Senior Developer Should Know - Part 1: var Keyword

9mac-dev — Tue, 11 Nov 2025 19:54:33 +0000

Part 1 of 6 - Essential Java 17+ features for senior developers upgrading from Java 8, 11, or 13.

The var keyword eliminates redundant type declarations, letting the compiler infer types from context. This article explores type inference rules, best practices, and shows why it's essential for modern Java development with the Stream API.

Why This Matters

Java has been criticized for verbosity forever. When modern languages got type inference decades ago, Java developers had to write types explicitly everywhere. By 2018, with the Stream API introducing complex generic types, the pain became unbearable:

Map<String, List<Transaction>> transactions = new HashMap<String, List<Transaction>>();

That's noise. The compiler already knows the type from the right side—why repeat it?

The var keyword (Java 10) solved this: "Let the compiler figure out the type, and let developers focus on logic."

What is var?

The var keyword lets the compiler automatically infer the type of a local variable from its initialization. It's NOT dynamic typing—the type is determined at compile-time and never changes.

var name = "John";                    // String
var count = 42;                       // int
var numbers = List.of(1, 2, 3);      // List<Integer>
var map = new HashMap<String, Integer>(); // HashMap<String, Integer>

// var eliminates repetition without sacrificing type safety

Key rules:

Only for local variables (not fields, parameters, or return types)
Must be initialized
Cannot change type after assignment

Simple Example

public class VarExample {
    public static void main(String[] args) {
        var greeting = "Hello, World!";
        var numbers = List.of(1, 2, 3, 4, 5);
        var total = numbers.stream()
            .mapToInt(Integer::intValue)
            .sum();

        System.out.println(greeting);
        System.out.println("Numbers: " + numbers);
        System.out.println("Total: " + total);
    }
}

Output:

Hello, World!
Numbers: [1, 2, 3, 4, 5]
Total: 15

Key Insight

var reduces boilerplate without sacrificing type safety. It's particularly valuable with the Stream API and complex generic types, where explicit types become noise rather than documentation.

When to Use var

✅ Perfect for:

// Long generic types - clarity without repetition
var customers = repository.findActiveCustomers();

// Stream operations - complex chains
var result = employees.stream()
    .filter(e -> e.salary() > 50000)
    .map(e -> e.name())
    .collect(Collectors.toList());

// Clear from context - type is obvious
var now = LocalDateTime.now();
var file = new File("data.txt");
var json = jsonParser.parse(data);

❌ Avoid when:

// Type is NOT obvious to reader
var result = calculateSomething(x, y);  // What type is result?

// Public API - type should be explicit
public var getData() { ... }  // Not allowed anyway

// Too cryptic abbreviations
var x = 10;  // Better: var count = 10;
var cfg = new Configuration();  // Better: var config = ...

Common Pitfalls

Don't initialize with null:

var x = null;  // Compiler error: cannot infer type from null

Can't use with multiple statements:

var name, age;  // Compile error: must initialize

// Instead use explicit types
String name;
int age;

Type is determined once and fixed:

var number = 42;       // int
number = "string";     // Compile error! number is int, not String

Read the Full Article

Discover much more in Part 1: Introduction & var Keyword on blog.9mac.dev:

Type inference with anonymous classes and intersection types
Advanced use cases with collections and functional interfaces
Best practices from production codebases
Common pitfalls and how to avoid them
15+ detailed examples with unit tests
Performance implications
Integration with other Java 17+ features

GitHub Repository

All code examples are ready to clone and run:

git clone https://github.com/dawid-swist/blog-9mac-dev-code.git
cd blog-post-examples/java/2025-10-25-java17-features-every-senior-developer-should-know
../../gradlew test

Next in the series: Part 2 - Records (immutable data carriers)

Forem: 9mac-dev

Java 17 Features Every Senior Developer Should Know - Part 6: Complete Reference Guide & Syntax Cheat Sheet

Complete Series Overview

Why This Matters

1. Less Boilerplate

2. More Safety

3. Better Readability

Quick Reference: All 6 Features at a Glance

var Keyword (Java 10) - Type Inference

Records (Java 16) - Immutable Data Carriers

Sealed Classes (Java 17) - Controlled Inheritance

Pattern Matching (Java 16) - Type Check + Cast

Switch Expressions (Java 14) - Value-Returning Switch

Text Blocks (Java 15) - Multi-line Strings

Real-World Integration Patterns

Pattern 1: Records + var for Clean Data

Pattern 2: Sealed Classes + Pattern Matching for Type Safety

Pattern 3: Text Blocks + var for Template Building

Pattern 4: Complete Domain Model (All Features Combined)

When to Use Each Feature

Use var When:

Use Records When:

Use Sealed Classes When:

Use Pattern Matching When:

Use Switch Expressions When:

Use Text Blocks When:

Decision Matrix

Key Insights

Full Articles & Examples

Complete Series

Run the Examples

Series Statistics

Java 17 Features Every Senior Developer Should Know - Part 5: Text Blocks

The Problem Text Blocks Solve

Why This Matters

What Are Text Blocks?

When to Use Text Blocks

Real-World Examples

Example 1: JSON Test Fixtures

Example 2: HTML Templates Without Escape Hell

Example 3: Email Template System

Example 4: Complex SQL with CTEs

Security Considerations (CRITICAL)

SQL Injection - The Danger Zone

The Safe SQL Pattern

XSS Injection - HTML Security

Advanced Patterns

Indentation Rules

Essential Space and Line Continuation

Relative Indentation Preserved

Key Insight

Read the Full Article

Java 17 Features - Part 4: Pattern Matching & Switch Expressions

Why This Matters

What is Pattern Matching?

Type Patterns (Java 16+)

Guarded Patterns (Java 16+)

Pattern Matching in Switch (Java 17+)

Real-World Example 1: equals() Implementation

Real-World Example 2: Switch Expressions

Real-World Example 3: Pattern Matching with Sealed Types

Real-World Example 4: Guarded Patterns

Real-World Example 5: Result Pattern

Key Insight

Read the Full Article

Clone and Run

Java #Java17 #PatternMatching #SwitchExpressions #Programming

Java 17 Features Every Senior Developer Should Know - Part 3: Sealed Classes

Why This Matters

What are Sealed Classes?

Exhaustive Pattern Matching

Key Insight

The Three Modifiers

1. sealed - Parent classes/interfaces that restrict extensions

2. final - Permitted subclasses that can't be extended further

3. non-sealed - Permitted subclass that can be extended by anyone

Real-World Example: Expression Evaluator

Common Patterns

Single Level Hierarchy

Multi-Level Hierarchy

1. `sealed` - Parent classes/interfaces that restrict extensions

2. `final` - Permitted subclasses that can't be extended further

3. `non-sealed` - Permitted subclass that can be extended by anyone