What I meant by "actual sealed classes" is two things, both currently
hypothetical, both related to least surprise:
1. Sealed classes that also worked as expected when you use them
through a Java framework combined with Groovy (evidently not
possible for JDK < 17).
2. Whether Groovy @Sealed is planned to support all (future) features
with regards to exhaustiveness etc the Java side is talking about
for JDK < 17 ?
I am not a big fan of sealed/private concepts in general, so this is not
an important topic for me. In the end not many things are as immutable
as a developer might think when designing a sealed hierarchy
(languages, currencies, planets in our solar system, states of matter,
...), which then creates the need for a forced major version upgrade,
since no other workaround is possible, due to the sealed nature of the
implementation. On the other hand the benefits of exhaustiveness, while
theoretically intriguing, are imho limited in practice, since errors of
this kind are in my experience a) easy to catch with tests, b) otherwise
pop up quickly & are trivial to pinpoint and c) are easily fixed.
I agree with your conclusion not to invest any effort here for now,
mg
On 23/09/2021 22:38, Paul King wrote:
Some replies inline.
On Fri, Sep 24, 2021 at 6:03 AM MG <mg...@arscreat.com
<mailto: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?
