Référence est ambiguë avec les génériques

JDK est droit. La 2e méthode n'est pas plus précis que le 1er. De JLS3#15.12.2.5

"Le secteur informel de l'intuition est qu'une méthode est plus spécifique que l'autre, si toute invocation gérées par la première méthode peut être transmise à l'autre sans un moment de la compilation type d'erreur."

Ce n'est clairement pas le cas ici. Je l'ai souligné toute invocation. La propriété d'une méthode plus spécifique que l'autre purement repose sur les deux méthodes elles-mêmes; elle ne change pas par invocation.

Analyse formelle sur votre problème: est-m2 plus spécifique que la m1?

m1: <R> void setValue(Parameter<R> parameter, R value) 
m2: <V> void setValue(Parameter<V> parameter, Field<V> value) 

D'abord, le compilateur doit en déduire R à partir de la première contraintes:

Parameter<V>   <<   Parameter<R>
Field<V>       <<   R

Le résultat est R=V, de par les règles d'inférence dans 15.12.2.7

Maintenant nous substituer R et vérifier le sous-type de relations

Parameter<V>   <:   Parameter<V>
Field<V>       <:   V

La 2e ligne ne tient pas, par sous-typage des règles en 4.10.2. Afin de m2 n'est pas plus spécifique que la m1.

V n'est pas Object dans cette analyse, l'analyse considère toutes les valeurs possibles de V.

Je suggère d'utiliser différents noms de méthode. La surcharge n'est jamais une nécessité.

---

Cela semble être un important bug dans Eclipse. La spec assez indique clairement que le type de variables ne sont pas remplacés dans cette étape. Eclipse ne semble variable de type substitution d'abord, puis méthode de contrôle de la spécificité de la relation.

Si un tel comportement est plus "sensible" dans certains exemples, il n'est pas dans d'autres exemples. Dire,

m1: <T extends Object> void check(List<T> list, T obj) { print("1"); }
m2: <T extends Number> void check(List<T> list, T num) { print("2"); }

void test()
    check( new ArrayList<Integer>(), new Integer(0) );

"Intuitivement", et officiellement par spec, le m2 est plus spécifique que la m1, et le test s'imprime "2". Toutefois, si la substitution T=Integer est faite en premier, les deux méthodes ne sont pas identiques!

---

pour la mise à Jour 2

m1: <R> void setValue(Parameter<R> parameter, R value) 
m2: <V> void setValue(Parameter<V> parameter, Field<V> value) 

m3: <T> void setValue2(Parameter<T> parameter, Field<T> value)
s4:             setValue(parameter, value)

Ici, m1 n'est pas applicable pour l'invocation de méthode s4, de sorte m2 est le seul choix.

Par 15.12.2.2, pour voir si m1 est applicable pour les s4, tout d'abord, l'inférence de type est effectué, à la conclusion que R=T; on vérifie ensuite Ai :< Si, ce qui conduit à Field<T> <: T, ce qui est faux.

Ceci est cohérent avec l'analyse précédente - si m1 est applicable à s4, toute invocation traitées par m2 (essentiellement les mêmes que s4) peuvent être traitées par m1, ce qui signifie m2 serait plus précis que le m1, ce qui est faux.

dans un type paramétré

Considérons le code suivant

class PF<T>
{
    public void setValue(Parameter<T> parameter, T value) {
    }

    public void setValue(Parameter<T> parameter, Field<T> value) {
    }
}

void test()

    PF<Object> pf2 = null;

    Parameter<Object> p2 = getP2();
    Field<Object> f2 = getF2();

    pf2.setValue(p2,f2);

Cette compile sans problème. Par 4.5.2, les types de méthodes dans PF<Object> sont des méthodes dans PF<T> avec la substitution T=Object. Qui est, les méthodes de pf2 sont

    public void setValue(Parameter<Object> parameter, Object value) 

    public void setValue(Parameter<Object> parameter, Field<Object> value) 

La 2e méthode est plus spécifique que le 1er.

Modifier: Cette réponse est fausse. Jetez un oeil à accepté de répondre.

Je pense que le problème vient de ce: compilateur ne pas voir le type de f2 (c'est à dire le Terrain) et le type inféré du paramètre formel (c'est à dire de Champ -> Champ) que le même type.

En d'autres termes, il ressemble type de f2 (Champ) est considéré comme un sous-type du type de paramètre formel de Champ (Domaine). Depuis le Champ est le même type d'un sous-type de l'Objet, le compilateur ne peut pas choisir une méthode plutôt qu'une autre.

Modifier: Permettez-moi de développer ma déclaration un peu

Les deux méthodes sont applicable et il semble que la Phase 1: Identifier Correspondant Arité de Méthodes Applicables par sous-typage est utilisé pour décider de la méthode à appeler et que les règles de Le choix de la Méthode Spécifique appliquée, mais a échoué pour une raison de choisir la deuxième méthode, plus de premier.

Phase 1 section utilise cette notation: X <: S (X est le sous-type de S). Basé sur ma compréhension de <:, X <: X est une expression valide, c'est à dire la <: n'est pas stricte et comprend le type lui-même (X est le sous-type de X) dans ce contexte. C'est ce qui explique le résultat de la Phase 1: les deux méthodes sont choisis comme candidats, depuis Field<Object> <: Object et Field<Object> <: Field<Object>.

Le choix de la Méthode Spécifique section utilise la même notation pour dire qu'une méthode est plus spécifique que l'autre. La partie intéressante du paragraphe qui commence par "Un fixe-arité de la méthode de membre nommé m est plus spécifique que l'autre membre...". Il a, entre autres choses:

Pour tout j de 1 à n, Tj <: Sj.

Cela me fait penser que dans notre cas de la deuxième méthode doit être choisis sur la première, parce que la suite est titulaire d':

• Parameter<Object> <: Parameter<Object>
• Field<Object> <: Object

alors que l'inverse ne tient pas en raison de Object <: Field<Object> être faux (l'Objet n'est pas un sous-type de Champ).

Remarque: Dans le cas des exemples de Chaîne, la Phase 1 s'il suffit de choisir la seule méthode applicable: le deuxième.

Donc, pour répondre à tes questions: je pense que c'est un bug dans le compilateur de mise en œuvre. Eclipse a c'est propre différentiels compilateur, ce qui n'a pas ce bug, il me semble.