Solución:
public abstract <T,K> T get (K entity);
es un método que puede tomar cualquier cosa como argumento y puede devolver cualquier cosa.
Anularlo con
public Integer get (DesiredClass entity)
no funciona, ya que restringe los tipos de argumentos que se pueden pasar al método a DesiredClass y, por lo tanto, rompe el principio de Liskov.
Sería más fácil de entender sin genéricos. Supongamos que tiene un método abstracto en la clase Bar:
public abstract void fillRecipient(Recipient r);
e intentas anularlo en SubBar con
public void fillRecipient(Glass glass) {
}
¿Qué haría el siguiente código si lo anterior fuera legal?
Bar bar = new SubBar();
bar.fillRecipient(new Mug());
Para completar la respuesta de JB Nizet, cuando escriba:
<K>
Significa implícitamente:
<K extends Object>
Ese método debe aceptar cualquier objeto. Limitándolo a DesiredClass en una subclase no sobrescribe nada, como dice el mensaje de error.
Los métodos anulados deben tener exactamente la misma firma, no se permiten subtipos / super tipos ni en los parámetros ni en los tipos de retorno.
Editar: en realidad, como se discutió en los comentarios, String public foo(); anula efectivamente Object public foo();.