I'll merge that PR and make the needed code changes to remove "@Incubating" from the respective sealed transforms.
Cheers, Paul. On Tue, May 5, 2026 at 10:18 PM Paul King <[email protected]> wrote: > > 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 > >
