Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.syntblaze.com/llms.txt

Use this file to discover all available pages before exploring further.

A non-sealed interface is a type declaration that explicitly opts out of the restricted inheritance hierarchy established by a parent sealed interface. By applying the non-sealed modifier, the interface re-opens the type hierarchy, allowing any arbitrary, unknown class or interface to implement or extend it without requiring explicit permission from the parent. In Java’s sealed classes architecture, any type permitted to extend or implement a sealed parent must explicitly declare its own sealing state to maintain hierarchy control. While classes have three modifier options (sealed, non-sealed, or final), interfaces inherently cannot be final. Therefore, an interface extending a sealed interface must be declared as either sealed or non-sealed. 
// The parent interface restricts its direct implementations
public sealed interface Shape permits Circle, Polygon {
    double calculateArea();
}

// A permitted class can be declared final to terminate the hierarchy
final class Circle implements Shape {
    public double calculateArea() { return 0.0; }
}

// A permitted interface cannot be final. 
// Using 'non-sealed' satisfies the compiler and re-opens this specific branch.
non-sealed interface Polygon extends Shape {
    int getNumberOfSides();
}

// Any unknown type can now extend or implement the non-sealed interface
interface IrregularPolygon extends Polygon {
    // Valid without needing permission from Polygon or Shape
}

class Hexagon implements Polygon {
    public double calculateArea() { return 0.0; }
    public int getNumberOfSides() { return 6; }
}
Technical Characteristics:
  • Hyphenated Contextual Keyword: non-sealed is the first and only hyphenated keyword in the Java language. It is a contextual keyword, meaning it only functions as a reserved modifier when placed in the modifier list of a class or interface declaration.
  • Exhaustiveness Checking: The presence of a non-sealed interface does not break exhaustiveness checking for pattern matching on the root sealed type. A switch expression on the parent sealed interface (e.g., Shape) remains fully exhaustive as long as all permitted direct subtypes (e.g., case Circle c and case Polygon p) are covered. A default clause is not required. Furthermore, when switching directly on the non-sealed type itself, exhaustiveness is achieved by providing an unconditional type pattern (e.g., case Polygon p ->), which also eliminates the need for a default keyword.
  • Asymmetric Transitivity: The non-sealed modifier affects only its own descendants. It does not invalidate the sealing of its parent. The parent sealed interface remains strictly sealed and continues to reject direct implementations from unpermitted types, while the branch originating from the non-sealed interface becomes entirely open.
Master Java with Deep Grasping Methodology!Learn More