Sealed classes -- Feedback on compiler message

[Alex Buckley]

On 6/6/2020 1:30 PM, Gunnar Morling wrote:
> I'm playing around a bit with sealed classes. As described in the JEP,
> the compiler rejects a subclass in another package when not compiling
> a named module. But the compiler error is not clear about the reason:
> 
>      class is not allowed to extend sealed class: org.acme.sealed.Shipment
> 
> Could it perhaps be a bit more specific, e.g.:
> 
>     class is not allowed to extend sealed class in another package when
> not compiling a named module: org.acme.sealed.Shipment

Another infelicity with the error message is that it doesn't make clear 
if `org.acme.sealed.Shipment` is the superclass or the subclass. Looking 
at javac's error templates for sealed classes:

http://hg.openjdk.java.net/jdk/jdk/file/e7a068a7f1d0/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties#l3441

this infelicity does _not_ occur in other messages, e.g. at line 3464:

   subclass {0} must extend sealed class

So, rather than:

   class is not allowed to extend sealed class: {0}

consider:

   class {0} in unnamed module cannot extend a sealed class in a 
different package

   class {0} in module {1} cannot extend a sealed class in a different 
module

Ideally, the relevant JLS text would live as comments in 
compiler.properties? In this case, the JLS draft for JEP 360 shows in 
8.1.6 that two scenarios exist, which would motivate two messages in 
compiler.properties:

   If a sealed class C belongs to a named module, then every class named 
in the permits clause of the declaration of C must belong to the same 
module than C; otherwise a compile-time error occurs.

   If a sealed class C belongs to an unnamed module, then every class 
named in the permits clause of the declaration of C must belong to the 
same package than C; otherwise or a compile-time error occurs.

Alex