Groovy 4 vs Java 17 sealed classes: can Groovy extend a sealed Java class?

Answer

Groovy 4 can compile a subclass that extends a Java 17 sealed class or interface, but the JVM will reject the class at load time with an IllegalAccessError (or IncompatibleClassChangeError) if the subclass is not listed in the sealed type’s permits clause. The Groovy compiler does not emit a compile‑time diagnostic for this violation, and @CompileStatic does not add any sealed‑class validation.

Confirmed facts

• Java 17 sealed classes enforce the permits rule during class loading.
• Groovy 4’s bytecode generator does not check the sealed contract; it simply emits a normal extends relationship.
• When the JVM loads a Groovy subclass that is not permitted, it throws IllegalAccessError.
• Static compilation with @CompileStatic only enables compile‑time type checks; it does not add sealed‑class validation.
• The enforcement is module‑aware: the same runtime check applies whether the sealed class and the Groovy subclass live in the same module or in different modules.

Reproducing the behaviour

1. Create a sealed Java class:

   // Base.java
   sealed class Base permits Allowed {}
   class Allowed extends Base {}
   

   Compile with javac Base.java.
2. Write a Groovy subclass that is not permitted:

   // Bad.groovy
   class Bad extends Base {}
   

   Compile with groovyc Bad.groovy.
3. Load the class from a Java program:

   public class Test {
       public static void main(String[] args) {
           try {
               Class.forName("Bad");
           } catch (Throwable t) {
               t.printStackTrace();
           }
       }
   }
   

   Run the program; you will see an IllegalAccessError indicating the sealed violation.

What this means for developers

Because the compiler does not warn, you must rely on runtime checks or manual code review to avoid sealed violations. If you need early detection, consider adding a static analysis step or using a custom lint rule that inspects Groovy bytecode for forbidden superclasses.

Missing diagnostic detail

If you are not experiencing the runtime error when loading the Groovy subclass, please confirm whether the class is actually referenced or loaded by the JVM. The error only occurs upon class initialization, so a class that is never loaded will not trigger the exception.