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
Some replies inline.
On Fri, Sep 24, 2021 at 6:03 AM MG 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
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
ava 11 or 8 seems
> less beneficial than it was a few years back.
>
>
>
> *From:* Mario Garcia
> *Sent:* Tuesday, September 21, 2021 3:10 AM
> *To:* dev@groovy.apache.org; Paul King
> *Subject:* [EXT] Re: [DISCUSS] Some potential additional system
> properties/CompilerConfi
] Re: [DISCUSS] Some potential additional system
properties/CompilerConfiguration flags for Groovy 4
External Email: Use caution with links and attachments.
Hi:
Here are my thoughts. Maybe I'm wrong but, if somebody is familiar with JDK17
sealed classes, I don't think that person would expect
Hi:
Here are my thoughts. Maybe I'm wrong but, if somebody is familiar with
JDK17 sealed classes, I don't think that person would expect that using
sealed syntax with JDK8 is going to output a JDK17 sealed class. I would
add it to the documentation and that's it.
To me seems that implementing
Hi folks,
[A bit of a long winded explanation but hopefully you will bear with me.]
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
