Is the permits relationship of Java Sealed classes/interfaces transitive

Question

If I read the JLS §8.1.6 and §9.1.4 correctly, the classes that a sealed class/interface permits, are just the direct subclasses/interfaces.

To illustrate this, consider the following example:

public sealed interface I1 permits I2, C, D { /*...*/ }
public final class C implements I1 { /*...*/ }
public final class D implements I1 { /*...*/ }

public sealed interface I2 extends I1 permits E, F { /*...*/ }
public final class E implements I2 { /*...*/ }
public final class F implements I2 { /*...*/ }

If I understand the specification correctly, I1 obviously permits C and D but not E and F (via the extends hierarchy of I2 from I1). Is this correct?

The reason I'm asking is what patterns are allowed for switch expressions of the following kind:

I1 i1 = // ...
return switch (i1) {
    case C c -> "1";
    case D d -> "2";
    case E e -> "3"; // Can we match over E?
    case F f -> "4"; // Can we match over F?
    default  -> "5";
};

Answer 1

I1 obviously permits C and D but not E and F. Is this correct?

More accurately, you can say that C and D are in the set of permitted direct subclasses of I1, which is a term defined in section 9.1.4. The JLS doesn't really define what "I1 permits C and D" means though.

As for your switch expression, the reason why it works is two-fold. First, you are able to write a type pattern in a switch label if the type of the switch selector expression is downcast-convertible to that type.

14.11.1

A pattern case element p is switch compatible with T if p is applicable at type T (14.30.3).

14.30.3:

A pattern p is said to be applicable at a type T if one of the following rules apply:

• A type pattern that declares a pattern variable of a reference type U is applicable at another reference type T if T is downcast convertible to U (5.5).

Obviously, E is downcast-convertible to I1 through a widening reference conversion, because E implements I1. Note that this fact has nothing to do with permits. It is simply a result of E implements I2 and I2 extends I1. Surely you would agree that implements and extends are transitive!

Second, switch expressions need to be exhaustive. Your switch expression is always exhaustive because it has a default case. However, it is still exhaustive even without the default case.

From now on, we will consider your switch expression but without the default case, because that is where permits plays a role. The rules to determine whether the set of case labels you wrote are exhaustive are specified in 14.11.1.1. The important bit of your case is (this is kind of an inductive definition):

• A set of case elements is exhaustive for a type T if it contains a pattern that is unconditional at type T (14.30.3).
• A set of case elements is exhaustive for a type T that includes an abstract and sealed class or interface named C, if it is exhaustive for every applicable permitted direct subtype of T.

"applicable permitted direct subtype of T" in your case is really just the same as "permitted direct subtype of T". You can also treat "a type T that includes an abstract and sealed class or interface named C" as the same as T - the "includes" relationship isn't relevant to your case. With T=I1 in mind, we can start "running" this algorithm.

We use the second rule first - the permitted direct subtypes of I1 are I2, C and D. Since we have a C c and D d in the case elements, we know that our set of case elements is exhaustive for C and D (first rule). Is it also exhaustive for I2? To determine that, we use the second rule again. The permitted direct subtypes of I2 are E and F. Using the first rule, we know that the case elements E e and F f are exhaustive for E and F respectively. We have now proven that that the set of case elements are exhaustive for I2, C and D, so it is exhaustive for I1, according to the second rule.

So if you are talking about how switch patterns work, I think "inductive" is a better word to describe how the exhaustiveness of switch case labels are verified.

Answer 2

If I read the JLS §8.1.6 and §9.1.4, correctly the classes that a sealed class/interface permits, are just the direct sub classes/interfaces.

Each sealed class or interface needs to specify at least one direct permitted class (or interface). There's no need to specify non-directs subclasses, they are granted with the permission by default (since they are allowed to extend their direct parent).

Specification explicitly tells that only direct subclasses can be provided in the permits clause, §8.1.6. Permitted Direct Subclasses:

Every permitted direct subclass specified by the permits clause must be a direct subclass of C (§8.1.4), or a compile-time error occurs.

Permitted classes should be necessarily marked with either of these modifiers: sealed, non-sealed and final (the latter modifier for obvious reasons can't be used with interfaces).

If a subclass is final it can't be extended.

By declaring a permitted subclass (subinterface) as non-sealed you're loosening the constraints. Such class is allowed to be extended as a regular class (no permits clause required).

If the subclass is being marked as sealed then the cycle repeats: it in turn has to have a permite clause specifying its direct subclasses.

Here's a quote from the JEP 409: Sealed Classes:

A sealed class imposes three constraints on its permitted subclasses:

1. The sealed class and its permitted subclasses must belong to the same module, and, if declared in an unnamed module, to the same package.

2. Every permitted subclass must directly extend the sealed class.

3. Every permitted subclass must use a modifier to describe how it propagates the sealing initiated by its superclass:

• A permitted subclass may be declared final to prevent its part of the class hierarchy from being extended further. (Record classes are implicitly declared final.)

• A permitted subclass may be declared sealed to allow its part of the hierarchy to be extended further than envisaged by its sealed superclass, but in a restricted fashion.

• A permitted subclass may be declared non-sealed so that its part of the hierarchy reverts to being open for extension by unknown subclasses. A sealed class cannot prevent its permitted subclasses from doing this.

That said, if you change the declaration of the sealed super interface I1 by specifying non-direct subclasses E and F after permits clause it would not compile:

public sealed interface I1
       permits I2, C, D, E, F {
    /*...*/
}

And we restore the initial declaration of I1 (by removing E and F) the following code would work fine

public static String foo(I1 i1) {
    
    return switch (i1) {
        case C c -> "1";
        case D d -> "2";
        case E e -> "3";
        case F f -> "4";
        default  -> "5";
    };
}

main()

public static void main(String[] args) {
    System.out.println(foo(new E()));
    System.out.println(foo(new F()));
}

Output:

3
4