Référence de constructeur ambigu dans javac mais pas dans Eclipse

Question

Eclipse 3.4. Java niveau du compilateur 1.6 JRE IBM 1.6

Nous avons une classe de bibliothèque que nous ne pouvons pas changer qui est de la forme.

import java.util.Hashtable; 
public class A extends Hashtable { 
    ... 
} 

Et nous avons construit une classe utilitaire pour fournir un accès facile à A.

public class B { 
    private A a; 
    public B() { 
    this.a = new A(); 
    } 
    public B(final A props) { 
    this.a = props; 
    } 
    public B(final Map<String, String> props) { 
    this(); 
    for (String key : props.keySet()) { 
     add(key, props.get(key)); 
    } 
    } 
    @SuppressWarnings("unchecked") 
    public B add(final String name, final Object value) { 
    a.put(name, value); 
    return this; 
    } 
} 

Le problème se produit lorsque nous essayons d'appeler l'un des constructeurs d'une autre classe.

public class C { 

    public void stuff() { 
    A a = new A(); 
    B b = new B(a);//Error in javac 
    } 
} 

Eclipse compile cela sans erreur, et quand il est compilé par javac ant et jenkins le compilateur donne une erreur comme suit.

reference to B is ambiguous, both method B(com.foo.A) in com.bar.B and method B(java.util.Map<java.lang.String,java.lang.String>) in com.bar.B match 
    [javac]   B b = new B(a); 

Cette erreur est-elle survenue dans javac? À mon avis, éclipse est correcte en sélectionnant la méthode plus spécifique.

Answer 1

Puisque HashTable implémente Map, il y a une ambiguïté. HThis réponse contient quelques idées de Goot:

Calling ambiguously overloaded constructor in Java

Answer 2

Comme la classe A étend Hashtable et Hashtable s'implémente l'interface de la carte, de sorte que vous pouvez dire la classe A obtient les propriétés de la carte et il devient également carte.

Lorsque vous rencontrez public B(final A props) et public B(final Map<String, String> props) Il est comme vous avez un argument de carte dans les deux constructeurs.

C'est pourquoi cela vous donne une certaine ambiguïté.

Answer 3

Le problème est qu'un constructeur accepte une table de hachage brute, tandis que l'autre accepte une carte paramétrée. Les deux constructeurs sont applicables, mais la logique de désambiguïsation ne fonctionne pas dans ce cas, car, pour Java Language Specification - un constructeur serait plus spécifique que l'autre seulement si son argument était un sous-type (strict) de l'autre argument. Le sous-typage non contrôlé n'est pas autorisé pendant cette étape, d'où l'ambiguïté.