Dies ist eine Art Nachfolgefrage in der Diskussion:
Warum nicht? t Arbeitet der Diamond-Operator in einem Aufruf von addAll () in Java 7?
Aus dem Java-Lernprogramm
Beachten Sie, dass der Diamant oft in Methodenaufrufen funktioniert; Aus Gründen der Übersichtlichkeit wird jedoch empfohlen, den Diamanten hauptsächlich zum Initialisieren einer Variablen zu verwenden, in der
deklariert ist
Also, ich bin etwas verwirrt über die erste Zeile. Wenn Diamant in Methodenaufrufen funktioniert?
Ein bisschen mehr Erklärung, wie Diamant-Operator funktioniert, finden Sie hier:
Ссылка ?
Und ich habe Folgendes versucht, was gut funktioniert:
Geben Sie mir Folgendes:
%Vor%ein Anruf wie folgt kompiliert:
%Vor% Der Typparameter beim Aufrufen des Konstruktors im Methodenaufruf von f() oben wird aus dem Argument für den Konstruktor abgeleitet (d. h. Integer ).
So ist das gemeint, wenn das Tutorial sagt
Beachten Sie, dass der Diamant oft in Methodenaufrufen funktioniert
Wenn nicht, kann jemand freundlich genug sein, um ein Beispiel zu geben, wo Diamant in Methodenaufruf funktioniert?
So ist das gemeint, wenn das Tutorial sagt
Ich denke ja, obwohl es ein paar Fehler gibt, wenn es um <> operators geht.
In Ihrem Fall ist die Box-Instanziierung kein Problem, da der Typ mithilfe des Konstruktorarguments trivial abgeleitet werden kann. Versuchen Sie, den Konstruktor so zu ändern, dass er ein Integer oder T nicht übernimmt und sehen Sie, wie der Aufruf fehlschlägt.
Sehen Sie sich auch diese Klasse an:
%Vor% Ebenso kann das Problem in Ihrer verknüpften Frage (in addAll ) einfach gelöst werden, indem Sie den Compiler ein bisschen wie folgt aushelfen:
Diamantoperatoren scheinen auch zu brechen, wenn es darum geht, anonyme Klassen wie folgt zu implementieren:
%Vor% Glücklicherweise erwähnt der Compiler in diesem Fall ziemlich explizit, dass <> nicht mit anonymen Klassen arbeitet.
Ich denke nicht, dass es sich lohnt, darüber nachzudenken, wann es funktioniert und wann nicht. Der Compiler wird es Ihnen sagen, und Sie müssen neu schreiben, was nicht funktioniert.
Es gibt keine echte Begründung dahinter; Es ist eher so, als hätten die Entwickler die aktuellen Einschränkungen der Implementierung des eigentlichen Compilers zu einem bestimmten Zeitpunkt in die Spezifikation aufgenommen und uns gesagt: So muss es sein.
Java 8 hebt viele dieser Einschränkungen auf, ohne dass die Hölle einfriert. ZB
%Vor%kompiliert mit Java 8 ohne Fehler. Und warum nicht?
Es geht nicht wirklich um Methodenaufruf. Die eigenständige Anweisung
%Vor% kompiliert auch. Es gibt genügend Informationen, um T für Box abzuleiten (d. H. Aus dem Integer-Argument)
Auf der anderen Seite kompiliert dies nicht
%Vor%Es gibt keine Möglichkeit zu wissen, welche Art von Liste gewünscht wird.
%Vor% Das funktioniert, weil Inferenz durch den Zieltyp Collection<String>
Tags und Links java java-7 diamond-operator