[sealed] @SafeVarargs on the methods of sealed class/interface
Remi Forax
forax at univ-mlv.fr
Sun Oct 25 12:35:39 UTC 2020
It means that safevarargs becomes a flag that needs to be verified by the VM because of separate compilation.
The current rules for @SafeVarargs avoid that by disallowing @SafeVarargs on instance method (the ones that can be overriden),
so the effect of @SafeVarargs is only local.
I'm not sure that changing the semantics of @SafeVarargs is a good idea because fundamentally @SafeVarargs as a work around the fact that arrays are mutable [*].
In the future, if we have immutable arrays (Array 2.0) and a way to support varargs (...) for such arrays, @SafeVarargs becomes useless.
regards,
Rémi
[*] or covariant, but it's too late for that bit
----- Mail original -----
> De: "Tagir Valeev" <amaembo at gmail.com>
> À: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Dimanche 25 Octobre 2020 02:29:17
> Objet: [sealed] @SafeVarargs on the methods of sealed class/interface
> Hello!
>
> As suggested by Lukas Eder on Twitter (
> https://mobile.twitter.com/lukaseder/status/1318890756250193920 ), it
> looks a good idea to allow SafeVarargs on the methods of sealed
> classes/interfaces. The rules could be the following:
> Check all the permitted subtypes. For every permitted subtype:
> - If it has this method overridden/implemented, then it must also be
> annotated as SafeVarargs
> - Otherwise, if the subtype is non-sealed, it's an error
> - Otherwise, the procedure is repeated for all the permitted subtypes
> of this subtype.
>
> What do you think?
>
> With best regards,
> Tagir Valeev.
More information about the amber-spec-experts
mailing list