Is it best practice to make sealed classes that lacks permits clause? [closed]

Question

A sealed class restricts which other classes can extend it, typically achieved using the permits clause. However, if a sealed class does not specify any permitted subclasses using the permits clause, it implicitly allows any class within the same compilation unit to extend it. This can lead to unintended inheritance, where classes that should not have been allowed to extend the sealed class can do so at any time.

Given this potential for unintended inheritance:

• should developers always include a permits clause when declaring a sealed class to explicitly control the permitted subclasses?
• Are there scenarios where omitting the permits clause might be justified or preferable, or is it generally advisable to specify it?

Answer 1

As you wrote:

A sealed class restricts which other classes can extend it, typically achieved using the permits clause. However, if a sealed class does not specify any permitted subclasses using the permits clause, it implicitly allows any class within the same compilation unit to extend it.

Refer to JLS 8.1.6 where this is specified (go to the end of the chapter).

In Java, the compilation unit is the *.java file (see JLS 7.3). This means that any "unintended inheritance" is impossible when a sealed class does not provide a permits clause – at least if you do not provide access to the source code, because you have to add the code for the extending class into the same source file as the sealed one. But even then that inheritance is not unintended.

But yes, all sealed classes and interfaces should provide a permits clause just to make it explicit which classes are allowed to extend/implement it.

Omitting the permits clause on a sealed class is just an indication of laziness, there is no scenario where it is advisable, justified or preferable.