Modern Java Features
Sealed Classes
Control class hierarchies using Sealed Classes introduced in Java 17.
Interview: Tests sealed class rules: permits declarations, subclass rules (final, sealed, non-sealed), and exhaustiveness integration.
Introduced in Java 17, Sealed Classes allow developers to restrict which subclasses can extend or implement a class or interface, providing control over inheritance design.
Core Idea
Sealing limits class hierarchies to a predetermined list of permitted subclasses.
Why It Matters
Prevents client developers from extending core classes in ways that violate package design invariants.
Interview Lens
Focuses on subclass modifiers: subclasses of sealed classes must be declared final, sealed, or non-sealed.
Subclass Rules
Any class permitted to extend a sealed class must declare one of the following modifiers:
final: Prevents further extension down the hierarchy (closes the branch).sealed: Continues a restricted hierarchy, listing its own permitted subclasses.non-sealed: Re-opens the hierarchy, permitting any subclass to extend it.
Code Walkthrough
This example demonstrates declaring a sealed Shape class and its permitted subclasses.
public sealed class Shape permits Circle, Square {}// Permitted subclasses must declare modifiers: final class Circle extends Shape {}
non-sealed class Square extends Shape {} // Square can be inherited by other classes
Interview-Relevant Information
Q: How do sealed classes integrate with pattern matching and switch?
Answer: Since the compiler knows all permitted subclasses of a sealed class at compile time, switch expressions on a sealed class instance are fully checked for exhaustiveness. If you cover all permitted subclasses, you do not need to supply a default block.
Quick Checklist
What three modifiers can a permitted subclass declare? How do sealed classes benefit switch expressions? If yes, you understand sealed hierarchies.
Use Cases
Modeling closed algebraic data types (ADTs) in compiler designs.
Safeguarding API payload hierarchies in enterprise SDKs.
Common Mistakes
Forgetting to declare final, sealed, or non-sealed on permitted subclasses, causing compilation failures.
Permitting classes in other packages without package-level module definitions (permitted classes must reside in the same package/module).