Ich habe die folgende Methode deklariert:
%Vor%Es wird von Clients aufgerufen, die etwas wie
verwenden %Vor%Die letzte Zeile oben erzeugt jedoch eine Warnung
Type safety: Ein generisches Array von Map wird für einen varargs-Parameter erstellt
Ich verstehe das nicht vollständig, aber ich denke, Varargs-Parameter werden in Arrays konvertiert, und es ist eine schlechte Idee, ein Array zu haben, dessen Typ eine generische Klasse ist (weil Generika invariant sind, Arrays dagegen nicht). .
Ich könnte dieses Problem lösen, indem ich die Methode als
neu einfüge %Vor%Aber das bringt die Last mit sich, die Zeilenobjekte in eine Liste auf dem Client zu setzen, was ich lieber vermeiden würde. Gibt es eine bessere Lösung?
Um die Argumente an eine varargs-Methode zu übergeben, platziert der Compiler die Argumente in ein Array.
Die Warnung soll Sie wissen lassen, dass der Compiler nicht garantieren kann, dass jedes der Elemente im Array - jedes der Argumente für die Methode "varags" - wirklich ein Map<String, Object> ist.
Dies ist ein bisschen eine nervige Warnung, da es keine Möglichkeit gibt, das zu umgehen, außer die Methodensignatur neu zu definieren, um Varargs nicht zu verwenden. IMO ist es sicher zu ignorieren, solange Sie ziemlich sicher sind, die tatsächlichen Laufzeittypen dieser Argumente (die in diesem Fall Sie sind).
Es gibt keine Möglichkeit, diese Warnung zu vermeiden, außer dass @SuppresWarning("unchecked") zur Methode hinzugefügt wird :)
Da Sie sagen, dass es sich um eine private Methode handelt, gibt es in diesem Fall keine "Clients" und Sie haben die Kontrolle über die Methode. Daher erscheint es sinnlos, die Warnung zu ignorieren.
Einige Male, als ich Methoden erstellt habe, die parametrisierte Typen als Varargs-Parameter verwenden, habe ich einige Überladungen erstellt:
%Vor%Das könnte einige der Warnungen vermeiden, abhängig davon, wie viele Argumente geliefert werden.
Sie können die Last der Verwendung einer Liste anstatt von varargs verringern, indem Sie eine Builder-Schnittstelle verwenden (z. B. wie die, die ich benutze ). Mit diesem CollectionBuilder würde es etwa so aussehen:
%Vor%es ist jedoch ohne generische args hübscher:
%Vor%Es ist sicherlich länger als die varargs Lösung, aber manchmal ziemlich praktisch.
Für alle, die hier landen, sind die Antworten etwas alt. Java 7 hat die Annotation @Safevarargs eingeführt, um das Problem zu beheben:
Aus dem Javadoc:
Eine Programmiererbehauptung, dass der Körper der annotierten Methode oder Konstruktor führt keine potenziell unsicheren Operationen auf seinem Varargs Parameter. Anwenden dieser Anmerkung auf eine Methode oder Konstruktor unterdrückt unkontrollierte Warnungen über a nicht-verifizierbar Variable Arity (Vararg) Typ und unterdrückt Ungeprüfte Warnungen zur parametrisierten Array-Erstellung beim Aufruf Websites.
Tags und Links java generics variadic-functions