Ogólna liczba niepowiązanych kolekcji

Question

Dlaczego kolekcje niezwiązane z klasą szablonów upuszczają swój typ? Oto przykład: (Niestety, nie będzie kompilować z powodu błędu jestem zagubiony.)

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) { 

     } 
    } 
} 

Ten kod generuje błąd przy kompilacji:

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

Gdybym określić szablon z B, takich jak B<String>, lub jeśli całkowicie usunę szablon z B, wszystko jest w porządku.

Co się dzieje?

EDIT: ludzie wskazał, nie było potrzeby, aby B generic więc dodałem do B

Answer 1

Tak, wiadomo, zachowanie, że w przypadku korzystania z surowego typu, a następnie wszystkie parametry typu na klasie zostaną utracone, a nie tylko parametr, którego nie udało się zadeklarować.

Problem jest częściowo tutaj:

Gdybym określić szablon B jak B<String>, lub jeśli usunąć szablon od B całkowicie, to wszystko jest w porządku.

To nie jest opcja, nie musisz wybierać, jeśli chcesz określić parametr typu, czy nie. Jedynym powodem, dla którego kompiluje się w ogóle bez określonego parametru, jest zgodność wsteczna. Zapisanie nowego kodu z brakującymi parametrami typu jest błędem programowania.

List<A> list = b.getList() nie interpretuje z powodzeniem typu, tylko skutecznie przykleja się do arbitralnej obsady i wierzy, że zadanie jest poprawne. Jeśli spojrzysz na ostrzeżenia kompilatora, generujesz ostrzeżenie o niebezpiecznej konwersji.

for(A a : b.getList()) {} uaktualnienia ostrzegające przed błędem, ponieważ wstawione odlewanie znajdowało się wewnątrz kodu generowanego przez kompilator, więc odmawia automatycznego generowania niebezpiecznego kodu, a nie tylko ostrzega.

Od specyfikacji języka Java:

Wykorzystanie surowców typów jest dozwolony tylko jako ustępstwo kompatybilności kodu starszego typu. Używanie typów surowych w kodzie napisanym po wprowadzeniu generyczności do języka programowania Java jest mocno odradzane. Możliwe, że przyszłe wersje języka programowania Java uniemożliwią stosowanie typów surowych.

Konkluzja naprawdę jest to, że jedyną istotną rzeczą rodzajowych java akcji z szablonami C++ jest <> składni :)

Więcej szczegółów: What is a raw type and why shouldn't we use it?

Answer 2

Po pierwsze, w Javie, to rodzajowych, a nie jak to jest Szablony w C++.

Deklarujesz ogólny parametr typu T w swojej klasie B, ale go nie używasz. Powinieneś używać T zamiast A w całej swojej definicji klasy B.

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

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

Następnie należy użyć parametru typu kiedy zadeklarować instancji klasy B.

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

Ale jeśli wiesz, że zmienna aList zawsze trzymać przedmiotów typu A jako nazwa metody getAList sugeruje, wtedy nie byłoby żadnego powodu, aby klasa B rodzajowy.

Answer 3

Jest to bardzo podobne do tego błędu:

6760983 : Unused type parameter triggering error in unrelated method

które jest zgłaszane tutaj:

Unused Generic causing problem