Компилятор Java: как два метода с одинаковым именем и разными сигнатурами могут соответствовать вызову метода? - PullRequest
Новая
       49

Компилятор Java: как два метода с одинаковым именем и разными сигнатурами могут соответствовать вызову метода?

9 голосов
/ 24 мая 2019

У меня есть этот класс с именем 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));
    }
}

и класс с именем 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;
    }
}

и, наконец, тестовый класс для класса Token 

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());
    }
}

Тест компилирует и запускает только файл в eclipse.

При построении на запятой 

mvn clean test

возникает ошибка компиляции: 

[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

Компиляция также завершается неудачно, когда я изменяю строку 21 на одну из

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

Когда я изменяю строку на одну из 

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

, компиляция прошла успешно.

Я не могу понять, почему возникает эта ошибка компиляции.

Я натолкнулся на следующие ссылки упаковка и распаковка , несколько универсальных типов и типов пересечений и эта ошибка компилятора eclipse , но я все еще не могу относиться к упомянутым причинам.

Мой вопрос: что заставляет компилятор думать, что обе сигнатуры метода verify совпадают, когда преобразователь String::valueOf передается методу get?

Для компиляциииспользуется следующий jdk (с maven и 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)

Ответы [ 2 ]

6 голосов
/ 24 мая 2019

Согласно JLS §15.12.2.2 :

Выражение аргумента считается относящимся к применимости для потенциально применимого метода m, если толькооно имеет одну из следующих форм:

  • Лямбда-выражение с неявным типом 1 .
  • Неточное выражение для ссылки на метод 2 .
  • [...]

Следовательно: 

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

лямбда-выражение неявного типа e -> String.valueOf(e) пропускается из проверки применимости во время разрешения перегрузки- оба метода verify(...) становятся применимыми - отсюда и неоднозначность.

Для сравнения приведем несколько примеров, которые будут работать, поскольку типы указаны явно: 

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

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

1 - неявно типизированное лямбда-выражение - это лямбда-выражение, в котором выводятся типы всех его формальных параметров. 2 - Неточная ссылка на метод - одна с несколькими перегрузками.

3 голосов
/ 24 мая 2019

Существует несколько реализаций String.valueOf(...) с разными аргументами.Компилятор не знает, какой из них вы хотите вызвать.Компилятор не способен увидеть, что все возможные методы действительно возвращают String, и поэтому не имеет значения, какой метод вызывается.Поскольку компилятор не знает, каким будет тип возвращаемого значения, он не может определить правильный Function<...,...> как тип выражения и поэтому не может понять, будет ли у вас под рукой Function или что-то еще, и поэтому не может сказать,хотите вызвать метод get с Function или Class.

Если вы вместо String::valueOf используете e -> String.valueOf(e), то компилятор может вывести немного больше, но этовсе еще не понимаю, что вы всегда будете возвращать String и, следовательно, будете интерпретировать его как Function<Object, Object>, с которым у вашего verify метода возникнут проблемы.

e -> e.toString Я не полностью понимаю, я не понимаю, почему компилятор не может выводить String в качестве возвращаемого типа здесь.Он выводит Object и делает то же самое, что и в предыдущем случае.Если вы разделите операцию на 

String s = tokens.get("baz", e -> e.toString());
verify("bat", s);  // line 21

, то она сработает, потому что компилятор может определить универсальный R из типа s.Точно так же он работает, явно указав R: 

verify("bat", tokens.<String>get("baz", e -> e.toString()));  // line 21

String.class, компилятор легко понимает, что вы хотите вызвать метод get(Class).

Object::toString имеет смысл работать, так как компилятор знает, что это будет Function<Object, String>.

...