Java 17 Features Interview Questions and Answers

Why Java 17 features are a favorite topic

Java 17 is the LTS release where a cluster of long-previewed language features finally became standard, and it is now a common production baseline. Interviewers ask about it because these features change how idiomatic Java looks — records, sealed types and pattern matching remove entire categories of boilerplate and bugs. A good answer shows you know the problem each one removes, not just its shape.

This page walks the Java 17 features that come up most, with runnable examples. To see where the language went next, pair it with the Java 21 features questions; for the LTS before it, see the Java 11 features set.

Q1. Why is Java 17 significant?

Java 17 is a Long-Term-Support release, so it became the standard upgrade target after Java 11 and receives extended support. It finalized records, sealed classes, pattern matching for instanceof, switch expressions and text blocks — features that had shipped as previews across Java 14–16 — into stable language elements.

The framing interviewers want is the timeline: Java 8 → 11 → 17 are the widely-adopted LTS steps, and 17 is where "modern Java" syntax became production-ready. Mentioning that many features arrived as previews first shows you understand how Java now evolves incrementally.

Q2. What is a record and when do you use one?

A record is a transparent, immutable carrier for a fixed set of values. You declare its components and the compiler generates the canonical constructor, private final fields, accessor methods, and correct equals, hashCode and toString. Use it for DTOs, value objects, map keys and return types that just bundle data.

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

Point p = new Point(1, 2);
p.x();                       // 1  — generated accessor (no "get" prefix)
p.equals(new Point(1, 2));   // true — value-based equals generated for you

The depth to add: records are implicitly final, their fields are final, and you can write a compact constructor to validate arguments. Because equals/hashCode are value-based, records make excellent map keys — which ties straight back to collections fundamentals.

Q3. What are sealed classes, and why pair them with pattern matching?

Sealed classes and interfaces restrict their subtypes to an explicit permits list, so the set of possible implementations is closed and known at compile time. That closed set lets the compiler verify a switch covers every case, making exhaustive pattern matching safe.

sealed interface Shape permits Circle, Square {}
record Circle(double radius) implements Shape {}
record Square(double side) implements Shape {}

double area(Shape s) {
    return switch (s) {                 // no default needed: set is closed
        case Circle c -> Math.PI * c.radius() * c.radius();
        case Square sq -> sq.side() * sq.side();
    };
}

The interviewer is checking whether you see why sealing matters: with a closed hierarchy the compiler knows every branch, so adding a new subtype later forces you to update every exhaustive switch — turning a runtime surprise into a compile error. Permitted subclasses must themselves be final, sealed, or non-sealed.

Q4. Explain pattern matching for instanceof.

It combines the type test and the cast: if (obj instanceof String s) checks the type and, when true, binds s as a String in scope. It removes the redundant cast that always followed a classic instanceof, and the binding is scoped so it is only visible where the type is guaranteed.

// Before: test then cast, repeating the type
if (obj instanceof String) {
    String s = (String) obj;
    return s.length();
}
// Java 16+/17: one step, no cast
if (obj instanceof String s) {
    return s.length();
}

A neat detail is flow scoping: if (!(obj instanceof String s)) return; /* s in scope here */ works because the compiler knows s is definitely a String past the guard. That flow-sensitive binding is what makes the feature more than syntactic sugar.

Q5. What are text blocks and what problem do they solve?

Text blocks are multi-line string literals delimited by """, letting you write JSON, SQL or HTML across several lines without escaping every quote or concatenating with \n. The compiler strips incidental leading indentation based on the closing delimiter's position.

String json = """
        {
          "name": "Ada",
          "role": "engineer"
        }
        """;

Two details worth knowing: incidental (common) indentation is removed while essential indentation is kept, and a trailing \ at line end suppresses the newline. Text blocks are still String, so nothing downstream changes — they only fix authoring ergonomics.

Q6. How are switch expressions different from switch statements?

A switch expression returns a value, uses arrow labels (case X -> ...) with no fall-through, supports multiple labels per branch, and must be exhaustive. This removes the classic switch bugs — forgotten break statements and missing cases — while producing an assignable result.

int days = switch (month) {
    case JAN, MAR, MAY, JUL, AUG, OCT, DEC -> 31;
    case APR, JUN, SEP, NOV -> 30;
    case FEB -> 28;
};

Because the expression must be exhaustive, an enum switch that misses a constant will not compile — the safety benefit. For blocks that need multiple statements, yield produces the branch's value. Contrasting "statement with break-based fall-through" against "expression that returns and cannot fall through" is the crisp answer.

Q7. Can a record implement an interface or add methods?

Yes. A record cannot extend a class (it implicitly extends java.lang.Record), but it can implement interfaces, declare additional methods, static members, and a compact constructor for validation. What it cannot do is add mutable instance fields — its state is exactly its components.

public record Money(long cents) implements Comparable<Money> {
    public Money {                       // compact constructor: validate
        if (cents < 0) throw new IllegalArgumentException("negative");
    }
    public int compareTo(Money o) { return Long.compare(cents, o.cents); }
}

The boundary to state clearly: records give you immutability and generated equality for free, but if you need mutable state or inheritance from a class, a record is the wrong tool. Knowing that limit is as important as knowing the feature.

Q8. How do these Java 17 features work together?

Sealed interfaces define a closed type hierarchy, records implement each variant compactly, and an exhaustive switch expression with pattern matching handles every case with compile-time completeness checking. Together they let you model algebraic-style data and process it safely without a default branch or manual casts.

This is the "have you actually used them" question. The strong answer is the Shape example from Q3 restated as a system: the sealed interface guarantees the switch is exhaustive, records remove the data-class boilerplate, and pattern matching removes the casts — three features solving one modeling problem cleanly.

How to prepare

Type these features out rather than reading them — build a small sealed Shape hierarchy with records and an exhaustive switch, and feel how adding a new subtype breaks compilation until you handle it. That experience is what makes your answer sound lived-in. Then place Java 17 in the release timeline against the Java 11 features before it and the Java 21 features after, so you can speak to how the language matured. Finish by rehearsing the "problem each feature removes" framing under follow-up pressure in a mock interview.