¿Qué es un tipo crudo?
La especificación del lenguaje Java define un tipo sin procesar de la siguiente manera:
Un tipo sin formato se define como uno de:
El tipo de referencia que se forma tomando el nombre de una declaración de tipo genérico sin una lista de argumentos de tipo acompañante.
Un tipo de matriz cuyo tipo de elemento es un tipo sin formato.
Un statictipo no miembro de un tipo sin formato Rque no se hereda de una superclase o superinterfaz de R.
Aquí hay un ejemplo para ilustrar:
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!)
}
}
Aquí, MyType<E>es un tipo parametrizado ( JLS 4.5 ). Es común referirse coloquialmente a este tipo simplemente MyTypepara abreviar, pero técnicamente el nombre es MyType<E>.
mttiene un tipo sin formato (y genera una advertencia de compilación) por el primer punto en la definición anterior; inntambién tiene un tipo sin formato en el tercer punto de viñeta
MyType.Nestedno es un tipo parametrizado, aunque es un tipo de miembro de un tipo parametrizado MyType<E>, porque lo es static.
mt1, y mt2ambos se declaran con parámetros de tipo reales, por lo que no son tipos sin formato.
¿Qué tienen de especial los tipos sin procesar?
Esencialmente, los tipos sin procesar se comportan tal como eran antes de que se introdujeran los genéricos. Es decir, lo siguiente es completamente legal en tiempo de compilación.
List names = new ArrayList(); // warning: raw type!
names.add("John");
names.add("Mary");
names.add(Boolean.FALSE); // not a compilation error!
El código anterior funciona bien, pero supongamos que también tiene lo siguiente:
for (Object o : names) {
String name = (String) o;
System.out.println(name);
} // throws ClassCastException!
// java.lang.Boolean cannot be cast to java.lang.String
Ahora nos encontramos con problemas en tiempo de ejecución, porque namescontiene algo que no es un instanceof String.
Presumiblemente, si solo desea namescontener String, tal vez aún podría usar un tipo sin formato y verificar manualmente cada add uno, y luego emitir manualmente a Stringcada elemento desde names. Aún mejor , aunque NO es usar un tipo sin procesar y dejar que el compilador haga todo el trabajo por usted , aprovechando el poder de los genéricos de Java.
List<String> names = new ArrayList<String>();
names.add("John");
names.add("Mary");
names.add(Boolean.FALSE); // compilation error!
Por supuesto, si QUÉ desea namespara permitir una Boolean, entonces se puede declarar como List<Object> names, y el código anterior se compilará.
Ver también
¿En qué se diferencia un tipo sin formato de usar <Object>como parámetros de tipo?
La siguiente es una cita de Effective Java 2nd Edition, Artículo 23: No use tipos sin procesar en el nuevo código :
¿Cuál es la diferencia entre el tipo sin formato Listy el tipo parametrizado List<Object>? Hablando en términos generales, el primero ha optado por la verificación de tipos genéricos, mientras que el segundo le dijo explícitamente al compilador que es capaz de contener objetos de cualquier tipo. Si bien puede pasar List<String>a un parámetro de tipo List, no puede pasarlo a un parámetro de tipo List<Object>. Hay reglas de subtipo para genéricos, y List<String>es un subtipo del tipo sin formato List, pero no del tipo parametrizado List<Object>. Como consecuencia, pierde seguridad de tipo si usa un tipo sin formato como List, pero no si usa un tipo con parámetros comoList<Object> .
Para ilustrar el punto, considere el siguiente método que toma List<Object>ay agrega a new Object().
void appendNewObject(List<Object> list) {
list.add(new Object());
}
Los genéricos en Java son invariables. A List<String>no es a List<Object>, por lo que lo siguiente generaría una advertencia de compilación:
List<String> names = new ArrayList<String>();
appendNewObject(names); // compilation error!
Si hubiera declarado appendNewObjecttomar un tipo sin formato Listcomo parámetro, esto se compilaría y, por lo tanto, perdería la seguridad de tipo que obtiene de los genéricos.
Ver también
¿En qué se diferencia un tipo sin formato del uso <?>como parámetro de tipo?
List<Object>, List<String>etc. son todos List<?>, por lo que puede ser tentador decir que son simplemente en su Listlugar. Sin embargo, hay una gran diferencia: dado que a List<E>solo define add(E), no puede agregar cualquier objeto arbitrario a a List<?>. Por otro lado, dado que el tipo sin Listformato no tiene seguridad de tipo, puede addcasi cualquier cosa para a List.
Considere la siguiente variación del fragmento anterior:
static void appendNewObject(List<?> list) {
list.add(new Object()); // compilation error!
}
//...
List<String> names = new ArrayList<String>();
appendNewObject(names); // this part is fine!
¡El compilador hizo un trabajo maravilloso al protegerlo de violar potencialmente la invariancia de tipo del List<?>! Si hubiera declarado el parámetro como tipo sin formato List list, el código se compilaría y violaría el tipo invariante de List<String> names.
Un tipo sin formato es el borrado de ese tipo
Volver a JLS 4.8:
Es posible utilizar como tipo la eliminación de un tipo parametrizado o la eliminación de un tipo de matriz cuyo tipo de elemento es un tipo parametrizado. Tal tipo se llama tipo crudo .
[...]
Las superclases (respectivamente, superinterfaces) de un tipo sin formato son los borrados de las superclases (superinterfaces) de cualquiera de las parametrizaciones del tipo genérico.
El tipo de constructor, método de instancia o no staticcampo de un tipo sin formato Cque no se hereda de sus superclases o superinterfaces es el tipo sin formato que corresponde a la eliminación de su tipo en la declaración genérica correspondiente a C.
En términos más simples, cuando se usa un tipo sin formato, los constructores, los métodos de instancia y los no staticcampos también se borran .
Tome el siguiente ejemplo:
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);
}
}
Cuando usamos el raw MyType, también getNamesse borra, ¡para que devuelva un raw List!
JLS 4.6 continúa explicando lo siguiente:
El borrado de tipos también asigna la firma de un constructor o método a una firma que no tiene tipos parametrizados o variables de tipo. El borrado de una firma de constructor o método ses una firma que consta del mismo nombre sy borra todos los tipos de parámetros formales dados en s.
El tipo de retorno de un método y los parámetros de tipo de un método genérico o constructor también se borran si se borra la firma del método o del constructor.
La eliminación de la firma de un método genérico no tiene parámetros de tipo.
El siguiente informe de error contiene algunas reflexiones de Maurizio Cimadamore, un desarrollador del compilador, y Alex Buckley, uno de los autores de JLS, sobre por qué debería ocurrir este tipo de comportamiento: https://bugs.openjdk.java.net/browse / JDK-6400189 . (En resumen, simplifica la especificación).
Si no es seguro, ¿por qué está permitido usar un tipo sin formato?
Aquí hay otra cita de JLS 4.8:
El uso de tipos sin formato solo se permite como una concesión a la compatibilidad del código heredado. Se desaconseja el uso de tipos sin formato en el código escrito después de la introducción de la genérica en el lenguaje de programación Java. Es posible que futuras versiones del lenguaje de programación Java no permitan el uso de tipos sin formato.
Efectivo Java 2nd Edition también tiene esto para agregar:
Dado que no debe usar tipos sin formato, ¿por qué los diseñadores de idiomas lo permitieron? Para proporcionar compatibilidad.
La plataforma Java estaba a punto de entrar en su segunda década cuando se introdujeron los genéricos, y existía una enorme cantidad de código Java que no usaba genéricos. Se consideró crítico que todo este código siga siendo legal e interoperable con el nuevo código que usa genéricos. Tenía que ser legal pasar instancias de tipos parametrizados a métodos diseñados para su uso con tipos normales, y viceversa. Este requisito, conocido como compatibilidad de migración , llevó a la decisión de admitir tipos sin formato.
En resumen, los tipos sin formato NUNCA deben usarse en un código nuevo. Siempre debe usar tipos parametrizados .
¿No hay excepciones?
Desafortunadamente, debido a que los genéricos de Java no están reificados, hay dos excepciones en las que se deben usar tipos sin formato en el nuevo código:
- Literales de clase, por ejemplo
List.class, noList<String>.class
instanceofoperando, por ejemplo o instanceof Set, noo instanceof Set<String>
Ver también