Reemplazando un método que usa borrado de tipo

Question

Hoy me encontré con algo interesante. Supongamos la siguiente clase de Java 6:

public class Ereasure { 

    public Object get(Object o) { 
     return null; // dummy 
    } 

    public static class Derived<T> extends Ereasure{ 
     // (1) 
     @Override 
     public Object get(T o) { 
       return super.get(o); 
     } 
     // (2) 
     /* 
     @Override 
     public Object get(Object o) { 
       return super.get(o); 
     }*/ 

    } 
} 

Si intenta compilar el ejemplo anterior, el compilador dice Ereasure.java:9: método no anula ni poner en práctica un método de un supertipo @ Override Si quita la anotación @Override (que no debería ser necesaria), dice Ereasure.java:8: name clash: get (T) en Ereasure.Derived y get (java.lang.Object) en Ereasure tiene la misma eliminación , sin embargo, ninguno reemplaza al otro Esto es un poco contradictorio, ya que T debe entrar en Object y, por lo tanto, anular el método get de las clases padre.

Si deja (1) no anotados y descomenta (2) (1) sobrecargas (2) tampoco funcionaría. salida del compilador:

Ereasure.java:15: get(T) is already defined in Ereasure.Derived 
    public Object get(Object o) { 

Como conclusión, T está siendo ereased al objeto, pero no puede anular el padre método GET.

Mi pregunta es ahora, ¿por qué no compila al menos uno de los ejemplos?

Answer 1

En una simple suposición, el compilador no usa la vista genérica al calcular sobrecargas que, por supuesto, no tendría sentido, porque a veces T podría ser Objeto, otras veces es de otro tipo. La anulación se volverá dependiente de un objetivo móvil T que es francamente erróneo, especialmente si hubiera múltiples métodos, todos llamados "get" pero con diferentes tipos de parámetros individuales. En tal caso, simplemente no tendría sentido y, en una suposición, eligieron simplemente mantener las cosas simples.

Answer 2

Se puede ver en el siguiente ejemplo por qué es imposible hacer lo que quiere:

public class Erasure { 

    public void set(Object o) { 
     return; 
    } 

    // method overloading: (which is valid) 
    public void set(String s) { 
     return; 
    } 

    public static class Derived<S> extends Erasure { 

     // Oops... which one am I supposed to override? 
     // (It would actually be overloading if S was a concrete type 
     // that is neither Object nor String.) 
     @Override 
     public void set(S o) { // does not compile 
     super.set(o); 
     } 
    } 
} 

La solución a su problema es que Erasure debe haber una clase parametrizada.

Answer 3

Considere un caso en el que tenga un getter y un setter anulados como genéricos.

Derived<String> d = new Derived<String(); 
Erasure e = d; 
e.set(new Object()); 
String s = d.get(); //Class cast exception 

El principio fundamental de los genéricos es que una excepción de difusión clase sólo puede suceder si hay o bien (a) una conversión explícita o (b) una advertencia. Si se le permitiera hacer lo que quería, lo anterior arrojaría una excepción sin ninguno de los dos.