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.
(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.
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?
