Java 17, released in September 2021, is the third Long-Term Support release, following Java 8 and Java 11. Unlike Java 11, which mostly polished existing APIs, Java 17 is where the language itself changed shape — sealed classes and records, both finalized in this release, give developers a genuinely new way to model data and restrict inheritance that simply did not exist in Java 8 or 11.

What Changed in Java 17?

Feature	What It Adds
Sealed classes and interfaces	Restrict which classes or interfaces may extend or implement a type, using `sealed` and `permits`
Records	Compact, immutable data carriers with auto-generated constructor, accessors, `equals()`, `hashCode()`, and `toString()`
Pattern matching for `instanceof`	Combines a type check and a cast into one expression, finalized in Java 16
Text blocks	Multi-line string literals without escape-character clutter, finalized in Java 15
Switch expressions	The `->` arrow form of `switch` that returns a value, finalized in Java 14
Strong encapsulation of JDK internals	Internal JDK APIs are no longer accessible by default, even with `--illegal-access` flags
Pattern matching for `switch`	Preview only in Java 17 — matching on a sealed type's subtypes directly in a `switch` case
Foreign Function & Memory API	An incubating API for calling native code and managing off-heap memory without JNI

Why Java 17 Mattered

A sealed interface's whole point is visible in one small diagram — the set of implementations is closed, named, and known at compile time, not left open to anything that happens to implement the interface later.

sealed interface Shape
        permits Circle, Square, Rectangle
              |
   +----------+----------+----------+
   |          |          |          |
Circle     Square    Rectangle   (nothing else is ever legal here)

No fourth implementation can compile against Shape from outside this permits list, which is exactly the guarantee a plain class hierarchy could never make.

Interview tip: if asked "what's the difference between sealed and final," the answer interviewers actually want is that final forbids all subclassing, while sealed allows a specific, named, finite set of subclasses — not "they're basically the same."

Modeling a fixed, closed set of related types used to mean either a plain class hierarchy anyone could extend, or a workaround like an enum with no room for per-case data.

Java

Try it out

// File: BeforeJava17.java

public class BeforeJava17 {

    static class Shape {}
    static class Circle extends Shape {
        double radius;
        Circle(double radius) { this.radius = radius; }
    }
    // Nothing here stops another class, anywhere in the codebase, from
    // also extending Shape - the set of possible shapes is never closed

    static double area(Shape shape) {
        if (shape instanceof Circle) {
            Circle c = (Circle) shape;
            return Math.PI * c.radius * c.radius;
        }
        throw new IllegalStateException("Unknown shape");
    }

    public static void main(String[] args) {
        Shape circle = new Circle(2.0);
        System.out.println("Circle area: " + area(circle));
    }
}

Output:
Circle area: 12.566370614359172

Sealed classes close that gap directly, and pattern matching for instanceof removes the separate explicit cast the old code needed.

Java

Try it out

// File: AfterJava17.java

public class AfterJava17 {

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

    static double area(Shape shape) {
        if (shape instanceof Circle c) {
            return Math.PI * c.radius() * c.radius();
        }
        throw new IllegalStateException("Unknown shape");
    }

    public static void main(String[] args) {
        Shape circle = new Circle(2.0);
        System.out.println("Circle area: " + area(circle));
    }
}

Output:
Circle area: 12.566370614359172

Shape now has exactly one permitted implementation by declaration, not by convention, and Circle needs no hand-written constructor, accessor, or cast at all.

A Tour of Java 17's Core Features

Sealed Classes and Interfaces

A sealed type declares exactly which classes or interfaces are allowed to extend or implement it, using a permits clause — anything not listed simply cannot compile against it. Every permitted direct subtype must itself be declared final, sealed, or non-sealed, so the set of possibilities stays fully known at every level.

Java

Try it out

// File: SealedShapeExample.java

public class SealedShapeExample {

    sealed interface Shape permits Circle, Square, Rectangle {}

    record Circle(double radius) implements Shape {}
    record Square(double side) implements Shape {}
    record Rectangle(double width, double height) implements Shape {}

    static double area(Shape shape) {
        if (shape instanceof Circle c) {
            return Math.PI * c.radius() * c.radius();
        } else if (shape instanceof Square s) {
            return s.side() * s.side();
        } else if (shape instanceof Rectangle r) {
            return r.width() * r.height();
        }
        throw new IllegalStateException("Unknown shape");
    }

    public static void main(String[] args) {
        Shape circle = new Circle(2.0);
        Shape square = new Square(3.0);

        System.out.println("Circle area: " + area(circle));
        System.out.println("Square area: " + area(square));
    }
}

Output:
Circle area: 12.566370614359172
Square area: 9.0

Shape here can never gain a fourth implementation from outside this file without editing the permits clause itself, which is what makes sealing valuable for a fixed set of cases like shapes, payment outcomes, or order states — the exact modeling this article's real-world example builds on. On its own, sealing does not make the if/else chain above exhaustiveness-checked by the compiler; that specific guarantee comes from pattern matching for switch, which was still a preview feature in Java 17 and is covered where it becomes final in this series' Java 21 article.

Records

A record declares its components once, in the header, and the compiler generates a canonical constructor, an accessor method per component, and equals(), hashCode(), and toString() implementations based on those components — a compact constructor can still validate input before it is stored.

Java

Try it out

// File: RecordBasicsExample.java

public class RecordBasicsExample {

    record Point(int x, int y) {
        Point {
            if (x < 0 || y < 0) {
                throw new IllegalArgumentException("Coordinates must not be negative");
            }
        }
    }

    public static void main(String[] args) {
        Point a = new Point(3, 4);
        Point b = new Point(3, 4);

        System.out.println("a: " + a);
        System.out.println("a.x(): " + a.x());
        System.out.println("a equals b: " + a.equals(b));

        try {
            new Point(-1, 5);
        } catch (IllegalArgumentException e) {
            System.out.println("Rejected: " + e.getMessage());
        }
    }
}

Output:
a: Point[x=3, y=4]
a.x(): 3
a equals b: true
Rejected: Coordinates must not be negative

Pattern Matching for instanceof

instanceof can now bind the matched value directly to a variable in the same expression, removing the separate cast that every earlier version required — already used throughout the examples above. The full mechanics, including scoping rules for the bound variable, are covered in this series' dedicated Pattern Matching article.

Text Blocks

Multi-line string literals, delimited with """, avoid the escape-character clutter of building something like a JSON payload or SQL query with + and \n. This series covers text blocks in full in its dedicated Text Blocks article.

Switch Expressions

The -> form of switch, which returns a value directly and requires no break, was finalized in Java 14 and remains unchanged in Java 17. The full syntax and rules around exhaustiveness for enums are covered in this series' dedicated Switch Expressions article.

Strong Encapsulation of JDK Internals

Starting in Java 17, internal JDK APIs — packages like sun.misc that were never meant for application use — are no longer accessible by reflection at all, even with the --illegal-access flag that previously offered an escape hatch. Any library still reaching into JDK internals needs to migrate to a supported public API before upgrading past Java 16.

Pattern Matching for switch (Preview) and the Foreign Function & Memory API (Incubator)

Two more features shipped in Java 17 but not as finished, stable APIs. Pattern matching for switch — writing a case Circle c -> branch directly against a sealed type — requires the --enable-preview flag in Java 17 and was not finalized until Java 21. The Foreign Function & Memory API, for calling native code and managing off-heap memory without JNI, shipped as an incubator module in Java 17, meaning its API was still expected to change before reaching a stable release. Neither is something to build production code against on Java 17 itself.

Real-World Example

A ticket-booking system needs to represent the outcome of a booking attempt as one of exactly three cases — confirmed, waitlisted, or failed — and handle each one distinctly, without an unrelated caller ever being able to invent a fourth outcome type.

Java

Try it out

// File: BookingResult.java

public sealed interface BookingResult
    permits BookingResult.Confirmed, BookingResult.Waitlisted, BookingResult.Failed {

    record Confirmed(String bookingId, int seatCount) implements BookingResult {}
    record Waitlisted(int position) implements BookingResult {}
    record Failed(String reason) implements BookingResult {}
}

Java

Try it out

// File: BookingService.java

public class BookingService {

    public BookingResult book(int requestedSeats, int availableSeats) {
        if (requestedSeats <= 0) {
            return new BookingResult.Failed("Requested seat count must be positive");
        }
        if (requestedSeats <= availableSeats) {
            String bookingId = "BMS-" + requestedSeats + "-" + availableSeats;
            return new BookingResult.Confirmed(bookingId, requestedSeats);
        }
        int waitlistPosition = requestedSeats - availableSeats;
        return new BookingResult.Waitlisted(waitlistPosition);
    }
}

Java

Try it out

// File: BookingResultDemo.java

public class BookingResultDemo {

    static String describe(BookingResult result) {
        if (result instanceof BookingResult.Confirmed c) {
            return "Confirmed as " + c.bookingId() + " for " + c.seatCount() + " seat(s)";
        } else if (result instanceof BookingResult.Waitlisted w) {
            return "Waitlisted at position " + w.position();
        } else if (result instanceof BookingResult.Failed f) {
            return "Failed: " + f.reason();
        }
        throw new IllegalStateException("Unknown booking result");
    }

    public static void main(String[] args) {
        BookingService service = new BookingService();

        BookingResult confirmed = service.book(2, 5);
        BookingResult waitlisted = service.book(6, 5);
        BookingResult failed = service.book(0, 5);

        System.out.println(describe(confirmed));
        System.out.println(describe(waitlisted));
        System.out.println(describe(failed));
    }
}

Output:
Confirmed as BMS-2-5 for 2 seat(s)
Waitlisted at position 1
Failed: Requested seat count must be positive

A mistake that appears often in fresher pull requests is modeling an outcome like this with a single class carrying a status enum plus a pile of optional fields — a bookingId that only makes sense when status == CONFIRMED, a position that only makes sense when status == WAITLISTED, and no compiler check tying the two together. Splitting each outcome into its own record under a sealed interface, exactly as BookingResult does here, makes an invalid combination like a Confirmed with a waitlist position impossible to construct in the first place, rather than merely undocumented.

Combining Java 17 Features With Each Other

Records implementing a sealed interface, exactly as BookingResult does above, is the core pattern Java 17 is built around — the sealed interface closes the set of cases, and each record supplies only the data that specific case actually needs. Pattern matching for instanceof is what makes reading those cases back out concise, binding the matched variable in the same line as the type check instead of a separate cast. Text blocks pair naturally with records used as simple DTOs, since a record's toString() output or a JSON payload built for it is often multi-line by nature.

Best Practices

Reach for a sealed interface with one record per case whenever a value can be exactly one of a small, known set of outcomes — a booking result, a payment result, a parse result — instead of a single class with a status flag and a pile of optional fields.

Use a record's compact constructor to validate input once, at construction time, rather than trusting every caller to check values before passing them in.

Keep records themselves free of business logic beyond simple derived accessors — a record represents data, and behavior that spans multiple records still belongs in a separate service class, exactly as BookingService does here.

Avoid pattern matching for switch in Java 17 production code, since it remains a preview feature requiring --enable-preview until Java 21 finalizes it.

Common Mistakes

Declaring a permitted subclass of a sealed type without one of final, sealed, or non-sealed does not compile — every direct subtype must pick exactly one, so the compiler always knows whether the hierarchy is still open at that point.

Java

Try it out

// This does not compile - Circle must be declared final, sealed, or non-sealed
sealed interface Shape permits Circle {}
class Circle implements Shape {}

Assuming a record's auto-generated equals() performs a deep comparison on an array-typed component is a second, easy-to-miss trap — arrays never override equals(), so a record's generated equals() compares them by reference, exactly like any other reference-typed component.

Java

Try it out

// File: RecordArrayMistake.java
import java.util.Arrays;

public class RecordArrayMistake {

    record Payload(String name, int[] values) {}

    public static void main(String[] args) {
        Payload a = new Payload("batch", new int[] {1, 2, 3});
        Payload b = new Payload("batch", new int[] {1, 2, 3});

        System.out.println("a equals b: " + a.equals(b));
        System.out.println("Arrays.equals: " + Arrays.equals(a.values(), b.values()));
    }
}

Output:
a equals b: false
Arrays.equals: true

Both arrays hold identical elements, but a.values() and b.values() are two distinct array objects, so the record's generated equals() reports them as unequal — a record with an array component needs a hand-written equals() if content-based comparison is actually required.

Interview Questions

Q1. What are the headline features Java 17 brought as an LTS release?

Sealed classes and records, both finalized in this release, are the two headline language features. Java 17 also carried forward pattern matching for instanceof, text blocks, and switch expressions from the non-LTS releases between 11 and 17, and strongly encapsulated JDK internal APIs. This is usually an opening question, so interviewers are mainly listening for whether you can distinguish what Java 17 actually finalized from what it merely carried forward.

Q2. What is a sealed class, and what problem does it solve?

A sealed class or interface uses sealed and a permits clause to declare exactly which other classes or interfaces may extend or implement it. It solves the problem of an "open" type hierarchy where any class, anywhere, can subclass a type never designed to be extended arbitrarily — useful for modeling a genuinely fixed set of cases, like a booking result or a payment outcome. The follow-up product-based interviewers ask is why this matters for exhaustiveness checking, which only pays off once pattern matching for switch is finalized in Java 21.

Q3. What are the modifier requirements for a class that directly extends a sealed class?

It must be declared exactly one of final (no further subclassing allowed), sealed (further restricted subclassing, with its own permits clause), or non-sealed (reopens unrestricted subclassing from that point on). Leaving off all three is a compile error, which is the exact detail service-based interviews check for since it's easy to get wrong from memory.

Q4. What does a Java record automatically generate, and what can you customize?

A record automatically generates a canonical constructor, a public accessor method per component, and equals(), hashCode(), and toString() implementations based on all components. A compact constructor can add validation without restating the parameter list, and additional non-canonical constructors are allowed as long as they eventually delegate to the canonical one. The nuance interviewers listen for is whether you know a record cannot declare additional instance fields beyond its components.

Q5. Why does comparing two records with an array component using equals() not behave the way you might expect?

Arrays in Java never override equals(), so comparing two array objects with ==-based equals() semantics compares references, not contents. A record's generated equals() does not special-case array components, so two records holding equal-content-but-different-instance arrays report as unequal unless the record's equals() is hand-written to use Arrays.equals() instead. This is a favorite product-company trick question precisely because it looks like it should just work.

Q6. Is pattern matching for switch available and stable in Java 17?

It is available only as a preview feature in Java 17, requiring the --enable-preview compiler and runtime flag, and its exact syntax was still subject to change. It was not finalized as a standard language feature until Java 21 — getting the version right here is exactly what separates a candidate who has actually used both releases from one reciting a feature list.

Q7. What happened to Java EE-related and other JDK-internal APIs by Java 17?

The Java EE modules removed in Java 11 stayed removed, and Java 17 went further by strongly encapsulating internal JDK APIs — packages never meant for application use became inaccessible by reflection entirely, even with the --illegal-access flag that had previously offered a workaround. Interviewers at companies running older codebases ask this specifically to gauge migration experience, not textbook knowledge.

FAQs

Is Java 17 an LTS release?

Yes, Java 17 is the third Long-Term Support release, following Java 8 and Java 11, and it received extended support well beyond the standard six-month release cycle.

Can a record implement an interface?

Yes. A record's implicit superclass is always java.lang.Record, but it can still implement any number of interfaces, including a sealed interface, exactly as Confirmed, Waitlisted, and Failed do in this article's real-world example.

Do records support additional, non-canonical constructors?

Yes, as long as every additional constructor eventually delegates to the canonical constructor via this(...), so the record's validation and field assignment logic stays in one place.

Is the permits clause always required on a sealed class?

No. If every permitted direct subtype is declared in the same source file as the sealed type, the compiler infers the permits clause automatically. It becomes required only once a permitted subtype lives in a separate file.

Can a sealed interface be implemented by a class in a different file?

Yes, as long as that class is in the same module as the sealed interface and is explicitly listed in the interface's permits clause — the clause cannot be inferred once the subtypes are spread across multiple files.

What's the difference between a sealed class and simply making a class final?

final prevents any subclassing at all. sealed allows subclassing, but only by an explicit, finite list of named classes or interfaces — useful when a type genuinely needs a small number of specific variants, rather than none at all.

Is the Foreign Function & Memory API ready to use in Java 17?

No, it shipped as an incubator module in Java 17, meaning its API surface was still expected to change in later releases and it was not intended for production use at that stage.

Summary

Java 17 is where the language itself gained new modeling tools — sealed classes close off a type hierarchy to a known, finite set of variants, and records eliminate the boilerplate of writing constructors, accessors, and equals()/hashCode()/toString() by hand for simple data carriers. Combined with pattern matching for instanceof, text blocks, and switch expressions carried over from earlier non-LTS releases, Java 17 is a substantially more expressive language than Java 11, even though its headline features arrived as an evolution rather than a single dramatic rewrite.

The habit worth carrying forward from this article's booking-result example is reaching for a sealed interface with one record per case whenever a value is genuinely one of a small, fixed set of outcomes, and remembering that a record's generated equals() still needs a hand-written override the moment an array component is involved.

What to Read Next

Continue Learning Modern Java

Next Step

Java 21 Features

Learn what's new in the Java 21 long-term support release.

→

Switch Expressions

Learn the newer, safer way to write a switch statement.

→

Duration

Learn how to measure a gap between two times.

→

Text Blocks

Learn how to write multi-line strings without messy escaping.

→

←

PreviousJava 11 Features

NextJava 21 Features

→