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.
