Some replies inline. On Fri, Sep 24, 2021 at 6:03 AM MG <mg...@arscreat.com> wrote:
> Hi Paul, > > I know you do not like them, but that again sounds like a perfect > example for an e.g. "WARNING: Use of sealed keyword with JDK < 17 leads > to @Sealed emulation behavior instead." or something along that line. > It isn't so much whether I like them or not. It is just an historical point to note that the current compiler design and approach has been to avoid using them. So adding them in is non-trivial. > (Warnings have the advantage that one can turn them off through a > standard mechanism, but can easily turn all back on again, to see what > Groovy is warning about, contrary to a switch which one has to know > about and which aborts at some point during compilation, not showing all > problems that will in the end be found.) > > If I understand this correctly, a flag would only make sense to me if it > is set by default, because then Groovy compilation would always > initially fail in the JDK < 17 case, alerting people to the fact that > their class is not really sealed. I cannot see someone educating himself > about the existence of the flag beforehand, but not knowing about the > fact that actual sealed classes require JDK 17. > It depends on what you mean by "actual sealed classes". As a Groovy user, sealed classes would always work by one of two mechanisms - one being the @Sealed annotation. Which mechanism is in play is totally transparent and is handled by the Groovy compiler. If I care also about Java integration, then only the native sealed mechanism would be known by a Java compiler. The proposed switch was something which folks who care about Java integration would need to educate themselves about. My take on the feedback is to keep it simple, so I won't implement for now. We can always add later if it proves of great interest and can't be handled by other means. > Cheers, > mg > > > > On 21/09/2021 09:40, Paul King wrote: > > For recent features like sealed classes and records*, we are moving > > towards implementations which support the feature natively (as per > > Java) when compiled with a suitable target bytecode version, and fall > > back to some alternate mechanism on older JDK versions. E.g. native > > sealed classes vs a @Sealed annotation. For sealed classes there are > > flags in CompilerConfiguration (and corresponding system properties) > > to give better control, e.g. do you still want the annotations even on > > a native sealed class. Feedback on the existing implementation is as > > always welcome but that is distinct from what I am asking here. > > > > Do folks think an additional flag would be useful that failed > > compilation if the native option wasn't enabled? > > >
