Quiz yourself: Classes, modules, and sealed types

Know what Java Language Specification 8.1.6 says about sealed-type hierarchies.

Read More: Oracle Java SE Programmer I Exam: Preparation Tips & Relevant 1Z0-808 Practice Tests

Given three classes that successfully compile

package com.foo;

public sealed class Super permits com.bar.SubBar, com.baz.SubBaz {

}

package com.bar;

import com.foo.Super;

public final class SubBar extends Super {

}

package com.baz;

import com.foo.Super;

public final class SubBaz extends Super {

}

Which statement is correct? Choose one.

A. The classes must belong to the unnamed module.

B. The classes must belong to the same unnamed or named module.

C. The classes must belong to a single named module.

D. The classes may belong to different named modules.

Answer. Sealed classes, developed under JEP 409, were initially introduced as a preview in Java 15 and finalized in Java 17. The code shown is a syntactically valid declaration of three classes in a sealed-class hierarchy.

Notice that the children refer to the parent using the extends clause, and the parent refers to the children using the permits clause. This is actually a circular reference and is indicative of the very tight coupling between the types of a sealed-type hierarchy. Indeed, the Java Language Specification 8.1.6 offers the following design guidance on the issue of sealed classes:

… a sealed class hierarchy should always be declared within a single maintenance domain, where the same developer or group of developers is responsible for maintaining the hierarchy.

In fact, the JLS imposes syntactic rules on the types in a sealed-type hierarchy, also in section 8.1.6. It notes the following:

If a sealed class C is associated with a named module, then every class specified in the permits clause of C’s declaration must be associated with the same module as C, or a compile-time error occurs.

If a sealed class C is associated with an unnamed module, then every class specified in the permits clause of C’s declaration must belong to the same package as C, or a compile-time error occurs.

The first of those two paragraphs says that the sealed class (Super) and its permitted subclasses (SubBar, SubBaz) must belong to the same module. From this you can determine that option D is incorrect and that option C is valid.

The second paragraph says that you cannot define a sealed-type hierarchy in an unnamed module if any of the types are in different packages. This tells you that options A and B are incorrect.

Since option C is now the only remaining valid option, you can finally be sure that it is the correct answer.

Side note: The circular references mentioned earlier (where the child types refer to the parent type in their extends clauses, and the parent type refers to the child types in the permits clause) combine with the module system rule that prohibits cyclic dependencies among modules. This prevents the types of the sealed-type hierarchy from being spread across modules.

Conclusion. The correct answer is option C.

Source: oracle.com