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 such scenario of compiler configuration is
going to be done for the sake of part of the 1/3 of the potential users:
- I would like to use sealed-classes -> use JDK17
- I love Groovy and I'd like to use sealed classes -> Use Groovy 4 and
JDK 17
- I love Groovy but I'm stuck in JDK8 OR I love Java and I'd like to use
sealed classes but again stuck in JDK8 -> Use Groovy 4 and be aware that,
although it looks like sealed classes, you're not using JDK17, so it
won't be the JDK17 sealed class
Anyway, I would wait until this is really a real concern rather than a
premature optimization and I would use that time and effort in other parts
of the language. You already mentioned it, I also think Codenarc could be a
good fit for this.
My two cents
El mar, 21 sept 2021 a las 9:41, Paul King (<pa...@asert.com.au>) escribió:
>
> 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
> 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?
>
> Here is an example to spell out the idea. The idea is that if I have:
>
> sealed class Shape { ... }
> final class Triangle extends Shape { ... }
> ...
>
> And then, if I compile with target bytecode at JDK17 I will get a sealed
> class (for Shape) as expected in the Java world but just one annotated
> with @Sealed if I use for instance JDK8. The target version is detected and
> used to switch between the two potential outcomes with already some flags
> to control the behavior a little. I wonder whether folks familiar with Java
> will be surprised that they use the `sealed` keyword but don't really get a
> sealed class and they are hoping to use the class as is with Java.
>
> It seems we have three options:
> (1) Leave as is. Our documentation explains the fallback scenarios, so
> users should familiarise themselves with it!
> (2) Provide an additional system property/flag/CompilerConfig setting
> which users could turn on and if the target bytecode version doesn't meet
> the required level for native support it would fail. The flag would be opt
> in, i.e. our existing best implementation based on version is the default
> but the flag would give a stricter option. With the flag set, if you
> compile my "sealed class" code on an old JDK it won't compile since I
> really meant to get a sealed class.
> (3) Leave this up to the next gen of CodeNarc Groovy 4 rules (not sure we
> have ever had version specific ones like this before).
>
> This example is around sealed classes but there will be similar concerns
> for records. Thoughts?
>
> * PR pending
>
> Cheers, Paul.
>
>
