[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