Java 17 became the default Java version for enterprise development not because of any single dramatic feature, but because it drew the line between old Java and modern Java. It dropped long-deprecated APIs, sealed the internal JDK APIs that frameworks had been using without permission, formalized features that had been in preview for two or three releases, and did it all under an LTS guarantee that meant production teams could actually depend on it.
If you are still on Java 8 or 11, understanding Java 17 is not optional — it is the prerequisite for everything that comes after, including virtual threads in Java 21. This article covers what Java 17 actually changes and why each change matters in production code.
Sealed Classes (JEP 409): Controlled Inheritance
Sealed classes let you declare exactly which classes can extend or implement a type. This is a capability that the type system previously had no way to express — you could either allow anyone to extend (open) or allow no one to extend (final). Sealed fills the gap: a specific, bounded set of permitted subtypes.
The practical consequence is that the compiler can enforce exhaustiveness when switching over a sealed type. If you have a sealed interface with three permitted implementations, a switch over it that does not cover all three will not compile. This turns a class of runtime errors — unhandled cases — into compile errors.
// Java 17+ — sealed classes with exhaustive switch (pattern matching for switch is Java 21)
// In Java 17, sealed classes enable exhaustive instanceof checks
public sealed interface PaymentResult
permits PaymentResult.Success, PaymentResult.Failure, PaymentResult.Pending {
record Success(String transactionId, double amount) implements PaymentResult {}
record Failure(String reason, int errorCode) implements PaymentResult {}
record Pending(String reference) implements PaymentResult {}
}
public class PaymentHandler {
// With sealed interface, the compiler knows every possible type
// Adding a new permitted type forces you to update this method
public String describe(PaymentResult result) {
if (result instanceof PaymentResult.Success s) {
return "Payment of " + s.amount() + " succeeded: " + s.transactionId();
} else if (result instanceof PaymentResult.Failure f) {
return "Payment failed (" + f.errorCode() + "): " + f.reason();
} else if (result instanceof PaymentResult.Pending p) {
return "Payment pending with reference: " + p.reference();
}
// Dead code — but without sealed, the compiler cannot verify this
throw new IllegalStateException("Unexpected: " + result);
}
// In Java 21+, this becomes a switch with pattern matching (preferred)
// In Java 17, the instanceof chain is the idiomatic form
}Code language: Java (java)Sealed classes are most valuable when used as algebraic data types — a bounded sum type where the sealed interface is the union and each permitted class is a variant. Payment results, API responses, validation outcomes, command types in a command pattern — anywhere you have a fixed set of meaningful states, a sealed type models it more accurately than an open class hierarchy.
Records (JEP 395): Immutable Data Carriers Without the Boilerplate
Records were finalized in Java 16 and are fully stable in Java 17. A record is a transparent, immutable data carrier: you declare the components, and the compiler generates the canonical constructor, accessor methods, equals, hashCode, and toString. What would have been 50 lines of a POJO is 1 line of a record.
Records are not a Lombok replacement — they are semantically different. A record’s identity is entirely determined by its components. Two records with the same component values are equal. Records are immutable by design (components are final). They cannot extend classes (only implement interfaces). These constraints are intentional — they make records safe to use as map keys, set elements, and in concurrent code without defensive copying.
// Java 16+ (stable in 17) — records for immutable data carriers
import java.util.Objects;
// Replaces ~50 lines of POJO boilerplate
// Constructor, accessors, equals, hashCode, toString generated by compiler
public record UserProfile(String username, String email, int age) {
// Compact constructor for validation — runs before field assignment
public UserProfile {
Objects.requireNonNull(username, "username must not be null");
Objects.requireNonNull(email, "email must not be null");
if (age < 0 || age > 150) throw new IllegalArgumentException("Invalid age: " + age);
// No explicit field assignment needed in compact constructor
}
// Can add custom methods — but cannot add fields
public boolean isAdult() {
return age >= 18;
}
}
// Records as value objects in domain modeling
public record Money(long amount, String currency) {
// Records can implement interfaces
public Money add(Money other) {
if (!this.currency.equals(other.currency)) {
throw new IllegalArgumentException("Currency mismatch");
}
return new Money(this.amount + other.amount, this.currency);
}
}
// Records work as map keys because equals/hashCode are based on components
// Map<UserProfile, List<Order>> ordersByUser = new HashMap<>();Code language: Java (java)Pattern Matching for instanceof (JEP 394): Eliminating the Cast
Before Java 16, every instanceof check was followed by a cast. The check and the cast both refer to the same type, making the cast redundant — the compiler already knows the type is correct. Pattern matching for instanceof eliminates the cast by binding the checked value to a typed variable in one expression.
This is not just syntax sugar. The pattern variable is only in scope where the compiler can verify the check holds, so it cannot be used incorrectly. In complex conditional logic with multiple instanceof checks, this reduces noise significantly and eliminates a class of ClassCastException bugs.
// Java 16+ (stable in 17) — pattern matching for instanceof
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
public class PatternMatchingExample {
private static final Logger log = LoggerFactory.getLogger(PatternMatchingExample.class);
public static double computeArea(Object shape) {
// Before Java 16: instanceof check followed by explicit cast
// if (shape instanceof Circle) { Circle c = (Circle) shape; ... }
// Java 16+: check and bind in one expression; no explicit cast needed
if (shape instanceof Circle c) {
return Math.PI * c.radius() * c.radius();
} else if (shape instanceof Rectangle r) {
return r.width() * r.height();
} else if (shape instanceof String s && !s.isBlank()) {
// Pattern variable 'c' is NOT in scope in the else-if — scoping is precise
log.warn("Cannot compute area of string: {}", s);
return 0;
}
throw new IllegalArgumentException("Unknown shape: " + shape);
}
// Works in conditions too — short-circuit evaluation controls scope
public static boolean isLargeCircle(Object obj) {
// 'c' only in scope in the true branch — prevents misuse
return obj instanceof Circle c && c.radius() > 100;
}
}Code language: Java (java)Strong Encapsulation of JDK Internals (JEP 403)
This is the Java 17 change most likely to break your existing code during migration, and it deserves attention even though it is not a new language feature. Java 9 introduced the module system and began the process of encapsulating internal JDK APIs — things in sun.* and com.sun.* packages that were never intended to be public APIs but became widely used because they exposed useful functionality that the standard library did not yet provide.
Java 17 makes this encapsulation strict. Previously, libraries could still access internal APIs with command-line flags. In Java 17, many internal APIs are simply inaccessible without explicit module opens in the JVM arguments. Common offenders include: Netty’s use of internal NIO APIs for performance, older serialization frameworks, libraries that use internal reflection mechanisms, and code that accesses sun.misc.Unsafe directly.
The migration path is to identify which libraries rely on internal APIs (check your startup logs for WARNING: An illegal reflective access operation has occurred on Java 11, or failures on Java 17), update those libraries to versions that use official APIs, and add --add-opens JVM flags as a temporary workaround for libraries that have not yet migrated.
Text Blocks (JEP 378): Multi-Line Strings Without Concatenation
Text blocks, stable since Java 15 and commonly used from Java 17, allow multi-line string literals without explicit newline characters or string concatenation. This matters most for embedded JSON, SQL queries, HTML templates, and any other multi-line content that appears as a string literal in code.
// Java 15+ (stable) — text blocks for multi-line string literals
public class TextBlockExample {
// Before: escape sequences and concatenation make content unreadable
private static final String JSON_BEFORE = "{
" +
" "userId": 42,
" +
" "action": "login",
" +
" "timestamp": "2024-01-01T00:00:00Z"
" +
"}";
// After: text block preserves formatting; leading whitespace stripped consistently
private static final String JSON_TEXT_BLOCK = """
{
"userId": 42,
"action": "login",
"timestamp": "2024-01-01T00:00:00Z"
}
""";
// SQL queries become readable
private static final String FIND_ACTIVE_USERS = """
SELECT u.id, u.username, u.email, COUNT(o.id) AS order_count
FROM users u
LEFT JOIN orders o ON u.id = o.user_id
WHERE u.status = 'ACTIVE'
AND u.created_at > :cutoffDate
GROUP BY u.id, u.username, u.email
ORDER BY order_count DESC
""";
// Methods like indent(), stripIndent(), and translateEscapes() work with text blocks
public static String formatForDisplay(String content) {
return content.stripIndent();
}
}Code language: Java (java)Switch Expressions (JEP 361): Switch That Returns a Value
Switch expressions, stable since Java 14, allow switch to be used as an expression — one that returns a value — rather than only as a statement. This eliminates the need for intermediate variables and makes the intent clearer. The arrow syntax also removes fall-through, eliminating a notorious source of bugs in traditional switch statements.
// Java 14+ (stable in 17) — switch expressions
public class SwitchExpressionExample {
// Switch as expression — returns a value directly
public static int daysInMonth(int month, int year) {
return switch (month) {
case 1, 3, 5, 7, 8, 10, 12 -> 31; // arrow syntax: no fall-through
case 4, 6, 9, 11 -> 30;
case 2 -> (year % 4 == 0 && (year % 100 != 0 || year % 400 == 0)) ? 29 : 28;
default -> throw new IllegalArgumentException("Invalid month: " + month);
};
}
// yield for multi-statement cases
public static String describe(int code) {
return switch (code) {
case 200 -> "OK";
case 201 -> "Created";
case 400 -> "Bad Request";
case 401, 403 -> {
String category = code == 401 ? "authentication" : "authorization";
yield "Client error: " + category; // yield returns from the block
}
case 500 -> "Internal Server Error";
default -> "Unknown: " + code;
};
}
}Code language: Java (java)Interview Questions
What happens if you add a new permitted type to a sealed interface that is used in instanceof-chain dispatch code?
In Java 17, with instanceof chains, nothing happens at compile time — the new type falls through all the instanceof checks and hits the default case or throws an exception. The compiler does not enforce exhaustiveness for instanceof chains. This is why pattern matching for switch (Java 21) is preferred — in a switch over a sealed type without a default, adding a new permitted type causes a compile error, forcing the developer to handle the new case. In Java 17, the standard practice is to include a final else clause that throws an explicit exception to catch unhandled cases at runtime.
How does the system behave when a library uses internal JDK APIs that were accessible in Java 11 but restricted in Java 17?
On Java 17, access to strongly encapsulated internal APIs throws InaccessibleObjectException at runtime when the library attempts reflective access, or fails with module system errors at startup if the library uses direct API calls. The application may start successfully but fail when specific code paths invoke the affected library features. The diagnostic path is checking startup logs for reflective access warnings on Java 11 (which become errors on Java 17), reviewing the library’s release notes for Java 17 compatibility, and using –add-opens as a temporary workaround while updating to a compatible library version.
What issues arise when a record is used as a key in a HashMap and a field is a mutable object?
Records generate equals and hashCode based on component values. If a component is a mutable object — a List, a Date, a custom mutable class — and that object is mutated after the record is used as a map key, the record’s hashCode changes. The map cannot find the record in its original bucket, and lookups return null even though the key is in the map. The record appears lost. This is the same bug that affects any mutable key in a hash-based collection. Records do not prevent this — they only ensure that equals and hashCode are consistent with each other based on current component values. The fix is to use only immutable components in records used as map keys.
Summary
Java 17 is important because it made a set of features permanent that had been in preview for years — sealed classes, records, pattern matching for instanceof, text blocks, switch expressions — and it enforced the module system boundaries that Java 9 introduced but did not fully enforce. For teams migrating from Java 8 or 11, Java 17 is the first version where modern Java feels complete rather than in progress. And it is the necessary stepping stone to Java 21’s virtual threads and full pattern matching for switch.
