Generische Verschraubungen nicht zusammenhängender Sammlungen

Question

Warum fallen Sammlungen, die nicht mit der Vorlagenklasse zusammenhängen, ihren Typ? Hier ein Beispiel: (Sorry, es wird nicht kompiliert, da der Fehler über Ich bin verwirrt.)

package test; 

import java.util.ArrayList; 
import java.util.List; 

public class TemplateTest { 

    public static class A { } 

    public static class B<T extends Comparable> { 
     List<A> aList = new ArrayList<A>(); 

     public List<A> getAList() { 
      return aList; 
     } 

     public int compare(T t, T t1) { 
      return t.compareTo(t1); 
     } 
    } 

    public static void main(String[] args) { 
     B b = new B(); 
     for (A a : b.getAList()) { //THIS DOES NOT WORK 

     } 
     List<A> aList = b.getAList(); //THIS WORKS 
     for (A a : aList) { 

     } 
    } 
} 

Dieser Code wirft einen Fehler bei der Zusammenstellung:

test/TemplateTest.java:24: incompatible types 
    found : java.lang.Object 
    required: test.TemplateTest.A 
     for (A a : b.getAList()) { 

Wenn ich die Vorlage angeben von B wie B<String>, oder wenn ich die Vorlage komplett aus B entferne, dann ist alles in Ordnung.

Was ist los?

EDIT: Leute darauf hingewiesen, gibt es keine Notwendigkeit ich generic B so zugesetzt, um war

Answer 1

Ja, ist es bekannt, Verhalten, dass wenn Sie ein Rohgewebe, dann Alle Typparameter der Klasse gehen verloren, nicht nur der Parameter auf Typpegel, den Sie nicht deklarieren konnten.

Die Frage ist zum Teil hier:

Wenn ich die Vorlage von B wie B<String> angeben, oder wenn ich die Vorlage von B vollständig entfernen, dann ist alles in Ordnung.

Das ist keine Option, Sie müssen nicht auswählen, ob Sie den Typparameter angeben möchten oder nicht. Der einzige Grund, warum es überhaupt ohne Parameter kompiliert wird, ist Rückwärtskompatibilität. Das Schreiben eines neuen Codes mit fehlenden Typparametern ist ein Programmierfehler.

List<A> list = b.getList() nicht erfolgreich den Typ zu interpretieren, es ist nur effektiv in einer willkürlichen Besetzung haften und Ihnen zu vertrauen, dass die Zuordnung korrekt ist. Wenn Sie sich die Compiler-Warnungen ansehen, wird in der Tat eine Warnung für eine unsichere Konvertierung erzeugt.

aktualisiert diese Warnung auf einen Fehler, da die eingefügte Umwandlung in Compiler-generiertem Code enthalten ist. Daher verweigert sie die automatische Generierung von unsicheren Code und gibt keine Warnung aus.

aus der Java-Sprachspezifikation:

Die Verwendung von rohen Typen von Legacy-Code nur als Zugeständnis an Kompatibilität erlaubt. Die Verwendung von Rohtypen in Code, der nach der Einführung der Generizität in die Java-Programmiersprache geschrieben wird, wird dringend empfohlen. . Es ist möglich, dass zukünftige Versionen der Programmiersprache Java die Verwendung von Rohtypen verbieten.

Unterm Strich ist wirklich, dass der einzige bedeutende Sache Java Generics Anteil mit C++ Vorlagen die < ist> Syntax :)

Weitere Details: What is a raw type and why shouldn't we use it?

Answer 2

Zuerst nach B, in Java, es ist Generics, nicht Vorlagen wie es in C++ ist.

Sie deklarieren einen generischen Typparameter T in Ihrer Klasse B, aber Sie verwenden ihn nicht. Sie sollten T anstelle von A in Ihrer B Klasse verwenden.

public static class B<T> { 
    List<T> aList = new ArrayList<T>(); 

    public List<T> getAList() { 
     return aList; 
    } 
} 

Dann sollten Sie einen Typ-Parameter verwenden, wenn Sie Ihre Instanz der Klasse B erklären.

B<A> b = new B<A>(); 

Aber wenn Sie wissen, dass Ihre aList variable Objekte vom Typ immer getAList schlägt A als Methodennamen halten wird, dann gäbe es keinen Grund, Klasse B Generika zu machen.

Answer 3

Dies ist zu diesem Fehler wirklich ähnlich:

6760983 : Unused type parameter triggering error in unrelated method

die hier berichtet wird:

Unused Generic causing problem