Méthode générique Covariance - restriction valide ou supervision du compilateur?

Question

Est-ce que quelqu'un sait la réponse définitive à pourquoi ce qui suit n'est pas autorisé par le compilateur java?

class BaseClass { 

     public <T extends Number> T getNumber(){ 
      return null; 
     } 
} 

class SubClass extends BaseClass{ 

     @Override 
     public <T extends Integer> T getNumber(){ 
      return null; 
     } 

} 

cela provoque le compilateur de se plaindre avec:

« La méthode getNumber() de type SubClass doit passer outre une méthode superclasse »

Maintenant, quand je mets à mes collègues certains ont essayé pour expliquer que cela va causer de la confusion avec le compilateur. Cependant, comme cela a également été souligné, ce qui suit, conceptuellement similaire, est compilable.

class BaseClass<T extends Number> { 
     public T getNumber(){ 
      return null; 

     } 
} 


class SubClass<T extends Integer> extends BaseClass<T>{ 
     @Override 
     public T getNumber(){ 
      return null; 

     } 
} 

Cela peut être abusé si la sous-classe appelle la super-implémentation, mais le compilateur fournit un avertissement à cet effet. Ma seule conclusion est que c'est un oubli de compilateur de la part des gens de Sun (je ne peux pas me résoudre à dire Oracle: -S).

Quelqu'un at-il la réponse définitive à celui-ci? Supposons qu'il soit en effet permis d'ajouter plus de restrictions au paramètre de type sur une classe dérivée.

Answer 1

Et si votre classe avait aussi une méthode <T extends Number> void setNumber(T number)?

BaseClass foo = new SubClass(); 
long longValue = 42; 
foo.<Long>setNumber(longValue); 

Le plus haut, serait accepté par le compilateur car BaseClass.setNumber accepte un paramètre de type dérivé de Number. Mais l'instance réelle n'accepte que des nombres entiers!

Vous pourriez faire valoir que si le paramètre de type est seulement utilisé pour la valeur de retour, il devrait automatiquement être considéré comme covariant. Mais alors le compilateur devrait s'assurer que vous n'utilisez pas le paramètre de type dans le corps de la méthode d'une manière non-covariante.

(En C# 4.0 this was actually solved, mais il implique marquer explicitement vos paramètres de type comme covariant ou contravariant avec les out et in mots-clés. Il était pas quelque chose qui pourrait simplement être autorisé par le compilateur sans changer la langue.)

Answer 2

I ne pas suivre tout à fait votre problème:

Lorsque j'ai implémenté votre première partie de code source et compilé en utilisant javac *.java, il compilé très bien. Cependant, si je changé votre méthode SubClass.getNumber() pour le faire ...

/* (non-Javadoc) 
    * @see constraint.base.BaseClass#getNumber() 
    */ 
@Override 
public <T extends Number> T getNumber() { 
    // TODO Auto-generated method stub 
    return super.getNumber(); 
} 

Je reçois l'erreur suivante:

SubClass.java:18: type parameters of <T>T cannot be determined; no unique maximal instance exists for type variable T with upper bounds T,java.lang.Number 
       return super.getNumber(); 
            ^
1 error 

La raison du code ci-dessus est que, en appelant super.getNumber(), le compilateur n » t ont une entrée qui infère le type T donc il ne peut pas déterminer ce T seront retournés par super.getNumber() et donc il ne peut pas satisfaire le type de retour avec SubClass.getNumber()

Maintenant, afin d'avoir obtenu l'erreur du compilateur, "The method getNumber() of type SubClass must override a superclass method", votre BaseClass aurait dû être résumé avec sa méthode getNumber().

Quant au 2ème morceau de code que vous avez fourni, la sous-classe peut, en effet, appeler super.getNumber() comme le compilateur saura (sur la compilation) que Type de paramètre générique du SubClass est déduit du type de paramètre de BaseClass. En plus de ça, je ne savais vraiment pas ce que vous essayiez de me demander.

Answer 3

@Wim Coenen fourni une bonne réponse.

Voici une petite clarification.

Si ce compilerait, qu'est-ce que vous attendez est arrivé:

import java.math.BigInteger; 

class BaseClass { 

    public <T extends Number> T getNumber(T n) { 
     System.out.println("Int value: " + n.intValue()); 
     return n; 
    } 
} 

class SubClass extends BaseClass { 

    @Override 
    public <T extends BigInteger> T getNumber(T n) { 
     System.out.println("Int value: " + n.intValue()); 

     // BigInteger specific! 
     System.out.println("Bit count: " + n.bitCount()); 
     return n; 
    } 
} 

public class Main { 
    public static void main(String[] args) { 
     BaseClass sub = new SubClass(); 

     // sub looks like a BaseClass... 
     // ...but since it's a SubClass it expects a BigInteger! 
     sub.getNumber(new Integer(5)); 
    } 
} 

Answer 4

Parce qu'il n'y a pas covariance ici. Covariance signifie «varie avec», et fait référence au type de retour variant en tant que type de classe conteneur. Cela ne se passe pas ici. Il n'y a pas de "co" dans votre covariance.