Hi folks, the functionality around sealed classes has been stable for some time yet remains in "incubating" status. I want to discuss moving it to final status before the GA version of 6.0.0.
The implementation evolved from its initial proposal in numerous ways which are now captured in a proposed revised version of the GEP[1]. As part of going to "Final", I wanted to add a "Stability commitment" section. I think it is easy to commit to maintaining the design choices we have delivered. The deferred features warrant more thought. Groovy takes a more relaxed stance on compiling all types within a sealed hierarchy at once, and also on checking that all types are in the same JPMS module. If we ever tighten those checks, existing code could break. So, the revised GEP proposes we only tighten checks via an opt-in setting (to be defined later if ever needed). The other "deferred" item is exhaustiveness checking. For that item, GEP-13 states that we wouldn't make the same stability commitment but will instead defer the choice to GEP-19 (Groovy 7). We could choose to make that opt-in also, but the sweet spot for sealed hierarchies is often considered to be the exhaustiveness checking[2], so making it cumbersome to use seems to defeat the purpose. I imagine we would only give warnings/errors with type checking enabled. Any thoughts on this proposal? Cheers, Paul. [1] https://github.com/apache/groovy-website/pull/76 [2] https://www.javacodegeeks.com/2026/04/sealed-classes-and-exhaustive-pattern-matching-how-they-change-api-design-not-just-syntax.html
