compilador Java: Como pode dois métodos com o mesmo nome e assinaturas diferentes coincidir com uma chamada de método?

A4L:

Eu tenho essa classe chamada Container:

public class Container {

    private final Map<String, Object> map = new HashMap<>();

    public void put(String name, Object value) {
        map.put(name, value);
    }

    public Container with(String name, Object value) {
        put(name, value);
        return this;
    }

    public Object get(String name) {
        return map.get(name);
    }

    public <R> R get(String name, Function<Object, R> mapper) {

        Object value = get(name);

        if (null == value) {
            return null;
        }

        return mapper
            .apply(value);
    }

    public <R> R get(String name, Class<R> type) {

        Object value = get(name);

        if (null == value) {
            return null;
        }

        if (type.isAssignableFrom(value.getClass())) {
            return type
                .cast(value);
        }

        throw new ClassCastException(String
            .format("%s -> %s", value.getClass(), type));
    }
}

ea classe chamada Token:

public class Token {

    private String value;

    public String getValue() {
        return value;
    }

    public void setValue(String value) {
        this.value = value;
    }

    public Token withValue(String value) {
        setValue(value);
        return this;
    }
}

e, finalmente, uma classe de teste para a Tokenclasse

public class TokenTest {

    @Test
    public void verifyToken() {
        verify("bar", new Token()
            .withValue("bar"));
    }

    @Test
    public void verifyContainer() {
        Container tokens = new Container()
            .with("foo", "bar")
            .with("baz", "bat");

        verify("bar", tokens.get("foo", String.class));
        verify("bat", tokens.get("baz", String::valueOf));  // line 21
    }

    private void verify(String expected, String actual) {
        verify(expected, new Token()
            .withValue(actual));
    }

    private void verify(String expected, Token actual) {
        Assert
            .assertEquals(expected, actual.getValue());
    }
}

As compilações de teste e corre apenas arquivo no eclipse.

Ao construir na linha commad

mvn clean test

um erro de compilação é levantada:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.0:testCompile (default-testCompile) on project ambiguous: Compilation failure
[ERROR] /C:/data/projects/java/ambiguous/src/test/java/ambiguous/TokenTest.java:[21,9] reference to verify is ambiguous
[ERROR]   both method verify(java.lang.String,java.lang.String) in ambiguous.TokenTest and method verify(java.lang.String,ambiguous.Token) in ambiguous.TokenTest match

A compilação também falha quando eu mudar de linha 21para um dos

verify("bat", tokens.get("baz", e -> String.valueOf(e)));
verify("bat", tokens.get("baz", e -> e.toString));

Quando eu mudar a linha para um dos

verify("bat", tokens.get("baz", String.class));
verify("bat", tokens.get("baz", Object::toString));

compilação for bem sucedida.

Eu não posso undestand por este erro compiliation é levantada.

Me deparei com as ligações follwong boxing e unboxing , vários tipos genéricos e tipos de interseção e este eclipse compilador bug mas eu ainda não pode se relacionar com as causas mencionadas.

A minha pergunta é, o que faz o compilador acha que ambas as assinaturas do verifymétodo estão combinando quando o mapeador String::valueOfé passado para o getmétodo?

Para compilação o seguinte jdk é usado (com Maven e Gradle):

$ java -version
openjdk version "1.8.0_201-1-ojdkbuild"
OpenJDK Runtime Environment (build 1.8.0_201-1-ojdkbuild-b09)
OpenJDK 64-Bit Server VM (build 25.201-b09, mixed mode)

Oleksandr Pyrohov:

De acordo com os JLS §15.12.2.2 :

Uma expressão argumento é considerado pertinente para aplicabilidade para um método potencialmente aplicáveis ma menos que tenha uma das seguintes formas:

• Uma expressão lambda tipo implícito ¹ .
• Uma expressão de referência método inexacta ² .
• [...]

Portanto:

verify("bar", tokens.get("foo", e -> String.valueOf(e)));

uma expressão lambda de tipo implícito e -> String.valueOf(e)é ignorada a partir da verificação de aplicabilidade durante a resolução de sobrecarga - ambos os verify(...)métodos se tornem aplicáveis - daí a ambigüidade.

Em comparação, aqui estão alguns exemplos que vão funcionar, porque os tipos são especificados explicitamente:

verify("bar", tokens.get("foo", (Function<Object, String>) e -> String.valueOf(e)));

verify("bar", tokens.get("foo", (Function<Object, String>) String::valueOf));

---

^{1 - Uma expressão lambda tipo implícito é uma expressão lambda, onde os tipos de todos os seus parâmetros formais são inferidos.
2 - Um método de referência inexacta - um com múltiplas sobrecargas.}