O que é um tipo bruto?
A Java Language Specification define um tipo bruto da seguinte maneira:
Um tipo bruto é definido como um dos seguintes:
O tipo de referência que é formado assumindo o nome de uma declaração de tipo genérica sem uma lista de argumentos de tipo associada.
Um tipo de matriz cujo tipo de elemento é um tipo bruto.
Um statictipo não membro de um tipo bruto Rque não é herdado de uma superclasse ou superinterface de R.
Aqui está um exemplo 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!)
}
}
Aqui, MyType<E>é um tipo parametrizado ( JLS 4.5 ). É comum referir-se coloquialmente a esse tipo simplesmente como MyTypeabreviação, mas tecnicamente o nome é MyType<E>.
mttem um tipo bruto (e gera um aviso de compilação) pelo primeiro marcador na definição acima; inntambém tem um tipo bruto pelo terceiro marcador.
MyType.Nestednão é um tipo parametrizado, mesmo que seja um tipo de membro de um tipo parametrizado MyType<E>, porque é static.
mt1e mt2são declarados com parâmetros de tipo reais, portanto, não são tipos brutos.
O que há de tão especial nos tipos brutos?
Essencialmente, os tipos brutos se comportam exatamente como eram antes da introdução dos genéricos. Ou seja, o seguinte é totalmente legal em tempo de compilação.
List names = new ArrayList(); // warning: raw type!
names.add("John");
names.add("Mary");
names.add(Boolean.FALSE); // not a compilation error!
O código acima funciona muito bem, mas suponha que você também tenha o seguinte:
for (Object o : names) {
String name = (String) o;
System.out.println(name);
} // throws ClassCastException!
// java.lang.Boolean cannot be cast to java.lang.String
Agora, enfrentamos problemas no tempo de execução, porque namescontém algo que não é instanceof String.
Presumivelmente, se você quiser namesconter apenas String, talvez ainda possa usar um tipo bruto e verificar manualmente todos os itens adde depois converter manualmente para Stringtodos os itens de names. Melhor ainda, NÃO é usar um tipo bruto e deixar o compilador fazer todo o trabalho para você , aproveitando o poder dos genéricos Java.
List<String> names = new ArrayList<String>();
names.add("John");
names.add("Mary");
names.add(Boolean.FALSE); // compilation error!
Claro, se você NÃO quer namespara permitir que um Boolean, então você pode declará-lo como List<Object> names, e o código acima seria compilar.
Veja também
Como um tipo bruto é diferente de usar <Object>como parâmetros de tipo?
A seguir, uma citação do Effective Java 2nd Edition, Item 23: Não use tipos brutos no novo código :
Qual é a diferença entre o tipo bruto Liste o tipo parametrizado List<Object>? Em termos gerais, o primeiro optou pela verificação de tipo genérico, enquanto o último disse explicitamente ao compilador que é capaz de armazenar objetos de qualquer tipo. Enquanto você pode passar um List<String>a um parâmetro do tipo List, você não pode passá-lo para um parâmetro do tipo List<Object>. Existem regras de subtipagem para genéricos e List<String>é um subtipo do tipo bruto List, mas não do tipo parametrizado List<Object>. Como conseqüência, você perde a segurança de tipo se usar um tipo bruto List, mas não se usar um tipo parametrizadoList<Object> .
Para ilustrar o ponto, considere o método a seguir, que pega a List<Object>e acrescenta a new Object().
void appendNewObject(List<Object> list) {
list.add(new Object());
}
Os genéricos em Java são invariantes. A List<String>não é a List<Object>, portanto, o seguinte geraria um aviso do compilador:
List<String> names = new ArrayList<String>();
appendNewObject(names); // compilation error!
Se você tivesse declarado usar appendNewObjectum tipo bruto Listcomo parâmetro, isso seria compilado e, portanto, você perderia a segurança de tipo obtida dos genéricos.
Veja também
Qual a diferença entre um tipo bruto e o uso <?>como parâmetro de tipo?
List<Object>, List<String>etc são todos List<?>, portanto, pode ser tentador dizer que eles são apenas o Listcontrário. No entanto, há uma grande diferença: como a List<E>define apenas add(E), você não pode adicionar qualquer objeto arbitrário a List<?>. Por outro lado, como o tipo bruto Listnão possui segurança de tipo, você pode addpraticamente qualquer coisa para a List.
Considere a seguinte variação do snippet anterior:
static void appendNewObject(List<?> list) {
list.add(new Object()); // compilation error!
}
//...
List<String> names = new ArrayList<String>();
appendNewObject(names); // this part is fine!
O compilador fez um trabalho maravilhoso ao proteger você de violar potencialmente a invariância de tipo do List<?>! Se você tivesse declarado o parâmetro como o tipo bruto List list, o código seria compilado e você violaria o tipo invariante List<String> names.
Um tipo bruto é o apagamento desse tipo
Voltar para JLS 4.8:
É possível usar como um tipo o apagamento de um tipo parametrizado ou o apagamento de um tipo de matriz cujo tipo de elemento é um tipo parametrizado. Esse tipo é chamado de tipo bruto .
[...]
As superclasses (respectivamente, superinterfaces) de um tipo bruto são apagamentos das superclasses (superinterfaces) de qualquer uma das parametrizações do tipo genérico.
O tipo de construtor, método de instância ou não staticcampo de um tipo bruto Cque não é herdado de suas superclasses ou superinterfaces é o tipo bruto que corresponde ao apagamento de seu tipo na declaração genérica correspondente a C.
Em termos mais simples, quando um tipo bruto é usado, os construtores, métodos de instância e não staticcampos também são apagados .
Veja o seguinte exemplo:
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 usamos o cru MyType, ele também getNamesé apagado, para que ele retorne um cru List!
O JLS 4.6 continua explicando o seguinte:
O apagamento de tipo também mapeia a assinatura de um construtor ou método para uma assinatura que não possui tipos ou variáveis de tipo parametrizados. O apagamento de uma assinatura de construtor ou método sé uma assinatura que consiste no mesmo nome se no apagamento de todos os tipos de parâmetros formais fornecidos em s.
O tipo de retorno de um método e os parâmetros de tipo de um método ou construtor genérico também sofrem apagamento se a assinatura do método ou construtor for apagada.
O apagamento da assinatura de um método genérico não possui parâmetros de tipo.
O relatório de bug a seguir contém algumas reflexões de Maurizio Cimadamore, um desenvolvedor de compiladores, e Alex Buckley, um dos autores do JLS, sobre por que esse tipo de comportamento deve ocorrer: https://bugs.openjdk.java.net/browse / JDK-6400189 . (Em resumo, isso simplifica a especificação.)
Se não é seguro, por que é permitido usar um tipo bruto?
Aqui está outra citação do JLS 4.8:
O uso de tipos brutos é permitido apenas como uma concessão à compatibilidade do código legado. O uso de tipos brutos no código escrito após a introdução da genéricos na linguagem de programação Java é fortemente desencorajado. É possível que versões futuras da linguagem de programação Java não permitam o uso de tipos brutos.
O Java 2nd Edition eficaz também tem isso a acrescentar:
Como você não deve usar tipos brutos, por que os designers de idiomas os permitiram? Para fornecer compatibilidade.
A plataforma Java estava prestes a entrar em sua segunda década, quando os genéricos foram introduzidos, e havia uma enorme quantidade de código Java existente que não usava genéricos. Foi considerado crítico que todo esse código permaneça legal e interoperável com o novo código que usa genéricos. Tinha que ser legal passar instâncias de tipos parametrizados para métodos projetados para uso com tipos comuns e vice-versa. Esse requisito, conhecido como compatibilidade de migração , levou a decisão de oferecer suporte a tipos brutos.
Em resumo, os tipos brutos NUNCA devem ser usados no novo código. Você sempre deve usar tipos parametrizados .
Não há exceções?
Infelizmente, como os genéricos Java não são reificados, há duas exceções em que os tipos brutos devem ser usados no novo código:
- Literais de classe, por exemplo
List.class, nãoList<String>.class
instanceofoperando, por exemplo o instanceof Set, nãoo instanceof Set<String>
Veja também