Duas opções para verificação do tipo de tempo de execução com genéricos:
Opção 1 - Corrompa seu construtor
Vamos supor que você esteja substituindo indexOf (...) e deseje verificar o tipo apenas para desempenho, para economizar a iteração de toda a coleção.
Faça um construtor imundo como este:
public MyCollection<T>(Class<T> t) {
this.t = t;
}
Em seguida, você pode usar isAssignableFrom para verificar o tipo.
public int indexOf(Object o) {
if (
o != null &&
!t.isAssignableFrom(o.getClass())
) return -1;
//...
Cada vez que você instancia seu objeto, você precisa se repetir:
new MyCollection<Apples>(Apples.class);
Você pode decidir que não vale a pena. Na implementação de ArrayList.indexOf (...) , eles não verificam se o tipo corresponde.
Opção 2 - Deixe falhar
Se você precisar usar um método abstrato que exija seu tipo desconhecido, tudo o que você realmente deseja é que o compilador pare de chorar sobre instanceof . Se você tem um método como este:
protected abstract void abstractMethod(T element);
Você pode usá-lo assim:
public int indexOf(Object o) {
try {
abstractMethod((T) o);
} catch (ClassCastException e) {
//...
Você está convertendo o objeto para T (seu tipo genérico), apenas para enganar o compilador. Seu elenco não faz nada em tempo de execução , mas você ainda receberá uma ClassCastException ao tentar passar o tipo errado de objeto para o seu método abstrato.
OBSERVAÇÃO 1: Se você estiver fazendo conversões adicionais não verificadas no seu método abstrato, suas ClassCastExceptions serão capturadas aqui. Isso pode ser bom ou ruim, então pense bem.
NOTA 2: Você recebe uma verificação nula gratuita ao usar instanceof . Como você não pode usá-lo, pode ser necessário verificar nulo com as próprias mãos.
Class.isAssignableFrom
.