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" <amae...@gmail.com> > À: "amber-spec-experts" <amber-spec-experts@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.