Che cos'è un tipo grezzo?
La specifica del linguaggio Java definisce un tipo non elaborato come segue:
Un tipo grezzo è definito come uno di:
Il tipo di riferimento che si forma prendendo il nome di una dichiarazione di tipo generico senza un elenco di argomenti di tipo associato.
Un tipo di matrice il cui tipo di elemento è un tipo non elaborato.
Un statictipo non membro di un tipo Rnon elaborato che non è ereditato da una superclasse o superinterfaccia di R.
Ecco un esempio per illustrare:
public class MyType<E> {
class Inner { }
static class Nested { }
public static void main(String[] args) {
MyType mt; // warning: MyType is a raw type
MyType.Inner inn; // warning: MyType.Inner is a raw type
MyType.Nested nest; // no warning: not parameterized type
MyType<Object> mt1; // no warning: type parameter given
MyType<?> mt2; // no warning: type parameter given (wildcard OK!)
}
}
Qui, MyType<E>è un tipo con parametri ( JLS 4.5 ). È comune riferirsi colloquialmente a questo tipo semplicemente come MyTypeabbreviazione, ma tecnicamente il nome è MyType<E>.
mtha un tipo non elaborato (e genera un avviso di compilazione) dal primo punto elenco nella definizione sopra; innha anche un tipo non elaborato dal terzo punto elenco.
MyType.Nestednon è un tipo con parametri, anche se è un tipo membro di un tipo con parametri MyType<E>, perché lo è static.
mt1e mt2sono entrambi dichiarati con parametri di tipo reali, quindi non sono tipi non elaborati.
Cosa c'è di così speciale nei tipi grezzi?
In sostanza, i tipi grezzi si comportano esattamente come prima dell'introduzione dei farmaci generici. Cioè, quanto segue è completamente legale in fase di compilazione.
List names = new ArrayList(); // warning: raw type!
names.add("John");
names.add("Mary");
names.add(Boolean.FALSE); // not a compilation error!
Il codice sopra funziona bene, ma supponiamo che tu abbia anche il seguente:
for (Object o : names) {
String name = (String) o;
System.out.println(name);
} // throws ClassCastException!
// java.lang.Boolean cannot be cast to java.lang.String
Ora ci troviamo in difficoltà in fase di esecuzione, perché namescontiene qualcosa che non è un instanceof String.
Presumibilmente, se si desidera namescontenere solo String, è possibile utilizzare comunque un tipo non elaborato e controllare manualmente tutti gli elementiadd , quindi eseguire manualmente il cast su Stringogni elemento names. Ancora meglio , sebbene NON sia usare un tipo grezzo e lasciare che il compilatore faccia tutto il lavoro per te , sfruttando la potenza dei generici Java.
List<String> names = new ArrayList<String>();
names.add("John");
names.add("Mary");
names.add(Boolean.FALSE); // compilation error!
Naturalmente, se si SI desidera namesdi consentire una Boolean, allora è possibile dichiarare come List<Object> names, e il codice di cui sopra sarebbe la compilazione.
Guarda anche
In che modo un tipo grezzo è diverso dall'uso <Object>come parametri di tipo?
Quella che segue è una citazione da Effective Java 2nd Edition, Item 23: Non usare tipi grezzi nel nuovo codice :
Qual è la differenza tra il tipo grezzo Liste il tipo parametrizzato List<Object>? In parole povere, il primo ha disattivato il controllo di tipo generico, mentre il secondo ha esplicitamente dichiarato al compilatore che è in grado di contenere oggetti di qualsiasi tipo. Mentre puoi passare List<String>a un parametro di tipo List, non puoi passarlo a un parametro di tipo List<Object>. Esistono regole di sottotipo per generici ed List<String>è un sottotipo di tipo raw List, ma non di tipo parametrizzato List<Object>. Di conseguenza, si perde la sicurezza del tipo se si utilizza un tipo grezzo simile List, ma non se si utilizza un tipo con parametri simileList<Object> .
Per illustrare il punto, considerare il seguente metodo che accetta a List<Object>e aggiunge a new Object().
void appendNewObject(List<Object> list) {
list.add(new Object());
}
I generici in Java sono invarianti. A List<String>non è a List<Object>, quindi quanto segue genererebbe un avviso del compilatore:
List<String> names = new ArrayList<String>();
appendNewObject(names); // compilation error!
Se avessi dichiarato appendNewObjectdi prendere un tipo Listnon elaborato come parametro, questo verrebbe compilato e perderai quindi la sicurezza del tipo che ottieni dai generici.
Guarda anche
In che modo un tipo grezzo è diverso dall'uso <?>come parametro di tipo?
List<Object>, List<String>ecc. sono tutti List<?>, quindi potrebbe essere allettante dire che sono solo Listinvece. Tuttavia, c'è una grande differenza: dal momento che a List<E>definisce solo add(E), non è possibile aggiungere qualsiasi oggetto arbitrario a List<?>. D'altra parte, dal momento che il tipo grezzo Listnon ha la sicurezza del tipo, puoi fare addqualsiasi cosa a List.
Considera la seguente variazione del frammento precedente:
static void appendNewObject(List<?> list) {
list.add(new Object()); // compilation error!
}
//...
List<String> names = new ArrayList<String>();
appendNewObject(names); // this part is fine!
Il compilatore ha fatto un ottimo lavoro nel proteggerti dal violare potenzialmente l'invarianza del tipo di List<?>! Se avessi dichiarato il parametro come tipo non elaborato List list, il codice verrebbe compilato e violeresti il tipo invariante List<String> names.
Un tipo grezzo è la cancellazione di quel tipo
Torna a JLS 4.8:
È possibile utilizzare come tipo la cancellazione di un tipo con parametri o la cancellazione di un tipo di array il cui tipo di elemento è un tipo con parametri. Tale tipo è chiamato tipo grezzo .
[...]
Le superclassi (rispettivamente, superinterfacce) di un tipo grezzo sono le cancellazioni delle superclasse (superinterfacce) di una qualsiasi delle parametrizzazioni del tipo generico.
Il tipo di un costruttore, metodo di istanza o non staticcampo di un tipo grezzo Cche non è ereditato dalle sue superclassi o superinterfacce è il tipo grezzo che corrisponde alla cancellazione del suo tipo nella dichiarazione generica corrispondente C.
In termini più semplici, quando viene utilizzato un tipo non staticelaborato, vengono eliminati anche i costruttori, i metodi di istanza e i non campi .
Prendi il seguente esempio:
class MyType<E> {
List<String> getNames() {
return Arrays.asList("John", "Mary");
}
public static void main(String[] args) {
MyType rawType = new MyType();
// unchecked warning!
// required: List<String> found: List
List<String> names = rawType.getNames();
// compilation error!
// incompatible types: Object cannot be converted to String
for (String str : rawType.getNames())
System.out.print(str);
}
}
Quando usiamo il raw MyType, anche questo getNamesviene cancellato, in modo che restituisca un raw List!
JLS 4.6 continua a spiegare quanto segue:
La cancellazione del tipo associa anche la firma di un costruttore o metodo a una firma che non ha tipi con parametri o variabili di tipo. La cancellazione della firma di un costruttore o di un metodo sè una firma composta dallo stesso nome se dalla cancellazione di tutti i tipi di parametri formali indicati s.
Anche il tipo restituito di un metodo e i parametri del tipo di un metodo generico o di un costruttore vengono cancellati se viene cancellata la firma del metodo o del costruttore.
La cancellazione della firma di un metodo generico non ha parametri di tipo.
La seguente segnalazione di bug contiene alcuni pensieri di Maurizio Cimadamore, un compilatore e Alex Buckley, uno degli autori del JLS, sul perché questo tipo di comportamento dovrebbe verificarsi: https://bugs.openjdk.java.net/browse / JDK-6400189 . (In breve, rende le specifiche più semplici.)
Se non è sicuro, perché è consentito utilizzare un tipo non elaborato?
Ecco un'altra citazione da JLS 4.8:
L'uso di tipi grezzi è consentito solo come concessione alla compatibilità del codice legacy. L'uso di tipi grezzi nel codice scritto dopo l'introduzione della genericità nel linguaggio di programmazione Java è fortemente scoraggiato. È possibile che le versioni future del linguaggio di programmazione Java non consentano l'utilizzo di tipi non elaborati.
Efficace Java 2nd Edition ha anche questo da aggiungere:
Dato che non dovresti usare tipi non elaborati, perché i designer linguistici li hanno autorizzati? Per fornire compatibilità.
La piattaforma Java stava per entrare nel suo secondo decennio quando furono introdotti i generici e esisteva un'enorme quantità di codice Java che non usava i generici. È stato ritenuto fondamentale che tutto questo codice rimanga legale e interoperabile con il nuovo codice che utilizza generici. Doveva essere legale passare istanze di tipi parametrizzati a metodi che erano progettati per l'uso con tipi ordinari e viceversa. Questo requisito, noto come compatibilità della migrazione , ha guidato la decisione di supportare tipi non elaborati.
In sintesi, i tipi non elaborati non devono MAI essere utilizzati nel nuovo codice. È necessario utilizzare sempre tipi con parametri .
Non ci sono eccezioni?
Sfortunatamente, poiché i generici Java non sono reificati, ci sono due eccezioni in cui i tipi non elaborati devono essere utilizzati nel nuovo codice:
- Letterali di classe, ad esempio
List.class, nonList<String>.class
instanceofoperando, ad es o instanceof Set. noo instanceof Set<String>
Guarda anche