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

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

The goal is to determine whether Groovy 4 can legally extend a sealed Java 17 class or interface, and if so, how the compiler and runtime enforce the sealed hierarchy.

Current observations indicate that Groovy 4’s compiler accepts subclasses of sealed Java types that are not listed in the permits clause, but the resulting bytecode may trigger an IllegalAccessError at class loading time. Additionally, the @CompileStatic annotation does not appear to perform compile‑time checks against sealed contracts.

Key constraints include:

• Java 17 sealed classes/interfaces are module‑aware and enforce subclass restrictions at load time.
• Groovy 4’s bytecode generation does not currently flag sealed violations during compilation.
• Runtime failures are observed when a Groovy subclass is not permitted by the sealed declaration.

Given these observations, the unresolved questions are:

• Does Groovy 4’s compiler provide any mechanism (e.g., diagnostics or annotations) to detect sealed class violations before runtime?
• Will future Groovy releases implement compile‑time enforcement of Java 17 sealed class restrictions?
• Can developers rely on @CompileStatic to catch sealed hierarchy violations, or is runtime error the only safeguard?