Этот допустимый Java?

Что ж, если я правильно понимаю третий пункт в первом списке из раздела 8.4.2 спецификации, в нем говорится, что ваши методы f () имеют одинаковую сигнатуру:

http://java.sun.com/ docs / books / jls / third_edition / html / classes.html # 38649

На этот вопрос действительно отвечает спецификация, а не наблюдаемое поведение компилятора X или IDE X. Все, что мы можем сказать, глядя на инструменты, - это то, как автор инструмента интерпретировал спецификацию.

Если мы применим третий пункт, мы получим:

...
    public static String f(List<String> list) {
        System.out.println("strings");
        return null;
    }

    public static Integer f(List<String> list) {
        System.out.println("numbers");
        return null;
    }
...

и сигнатуры совпадают, значит, есть коллизия, и код не должен компилироваться.

Также работает (на этот раз с sun java 1.6.0_16)

import java.util.Arrays;
import java.util.List;

class RealyCompilesAndRunsFine {

    public static String f(List<String> list) {
        return list.get(0);
    }

    public static Integer f(List<Integer> list) {
        return list.get(0);
    }

    public static void main(String[] args) {
        final String string = f(Arrays.asList("asdf"));
        final Integer integer = f(Arrays.asList(123));
        System.out.println(string);
        System.out.println(integer);
    }

}

--- Отредактировано в ответ на комментарии ниже ---

Хорошо, значит, это допустимая Java, но не должна быть. Ключ в том, что на самом деле он не полагается на возвращаемый тип, а на стертый параметр Generics.

Это не сработает для нестатических методов и явно запрещено для нестатических методов. Попытка сделать это в классе не удалась бы из-за дополнительных проблем, во-первых, типичный класс не final , как класс Class .

Это несоответствие во всем остальном довольно последовательном языке. Я рискну и скажу, что это должно быть незаконным, даже если это технически разрешено. На самом деле это ничего не добавляет к удобочитаемости языка и мало что добавляет к способности решать значимые проблемы. Единственная значимая проблема, которую он, кажется, решает, заключается в том, достаточно ли вы знакомы с языком, чтобы знать, когда его основные принципы , по-видимому, нарушаются внутренними несогласованностями языка в устранении стирания типов, обобщений и результирующих сигнатур методов. .

Определенно кода следует избегать, поскольку решить одну и ту же проблему любым количеством более значимых способов тривиально, и единственное преимущество состоит в том, чтобы увидеть, знает ли рецензент / расширитель пыльный грязный уголок спецификации языка.

--- Исходное сообщение следует ---

Хотя компиляторы могли разрешить это, ответ все равно отрицательный.

Стирание превратит List и List в неукрашенный список. Это означает, что оба ваших метода «f» будут иметь одинаковую сигнатуру, но разные типы возвращаемых значений. Тип возвращаемого значения нельзя использовать для различения методов, потому что это не удастся, когда вы вернетесь к общему супертипу; например:

Object o = f(Arrays.asList("asdf"));

Вы пробовали записывать возвращаемые значения в переменные? Возможно, компилятор оптимизировал ситуацию таким образом, что не наступает на правильный код ошибки.

Один вопрос, на который не был дан ответ: почему это вызывает только ошибку компиляции в Eclipse 3.6?

Вот почему: это функция .

В javac 7 рассматриваются два метода дубликаты (или ошибка совпадения имен) независимо от их возвращаемых типов.

Это поведение теперь более последовательное. с javac 1.5, который сообщил имя коллизия ошибок в методах и игнорирование их возвращаемые типы. Только в 1.6 была внесено изменение, которое включает типы возвращаемых значений при обнаружении повторяющихся методов.

Мы решили внести это изменение на всех уровнях соответствия (1,5, 1.6, 1.7) в версии 3.6, поэтому пользователи не будут удивлены изменением, если они скомпилировать их код с помощью javac 7.

Она действительна в соответствии со спецификацией.

Подпись метода m1 является подписью подписи метода m2, если либо

• m2 имеет ту же подпись, что и m1, либо

• подпись m1 является такой же, как и стертая подпись m2.

Таким образом, это не подсигнатуры друг друга, потому что стирание List не является List и наоборот.

Две сигнатуры методов m1 и m2 являются эквивалентны, если либо m1 является подпризнак m2 или m2 является подпризнаком подпризнаком m1.

Таким образом, эти два выражения не являются эквивалентными при перегрузке (обратите внимание на iff). А правило перегрузки гласит:

Если два метода класса (независимо от того. оба объявлены в одном классе, или оба наследуются классом, или один объявленный и один унаследованный) имеют одинаковое имя, но сигнатуры не эквивалентными, то метод считается перегруженным.

Следовательно, эти два метода перегружены, и все должно работать.

Насколько я могу судить, файл .class может содержать оба метода, поскольку дескриптор метода содержит параметры, а также тип возвращаемого значения. Если бы тип возвращаемого значения был таким же, то дескрипторы были бы такими же, и методы были бы неразличимы после стирания типа (следовательно, он не работает и с void). http://java.sun.com/docs/books/jvms/second_edition/html/ClassFile.doc.html#7035

Теперь для вызова метода с invoke_virtual требуется дескриптор метода, поэтому вы можете скажите, какой из методов вы хотите вызвать, поэтому кажется, что все эти компиляторы, которые все еще имеют общую информацию, просто помещают дескриптор для метода, который соответствует универсальному типу параметра, поэтому он жестко закодирован в байт-коде, который метод для вызова (в зависимости от их дескрипторов или, точнее, типа возвращаемого значения в этих дескрипторах), даже если параметр теперь является списком, без общей информации.

Хотя я нахожу эту практику немного сомнительной, я должен сказать, что мне нравится то, что вы можете это делать, и я считаю, что дженерики должны были быть разработаны для того, чтобы они могли работать таким образом (да, я знаю, что это создало бы проблемы с обратной совместимостью).

Похоже, компилятор выбирает наиболее конкретный метод на основе универсальных шаблонов.

import java.util.Arrays;
import java.util.List;

class TestWillThatCompile {

public static Object f(List<?> list) {
    System.out.println("strings");
    return null;
}

public static Integer f(List<Integer> list) {
    System.out.println("numbers");
    return null;
}

public static void main(String[] args) {
    f(Arrays.asList("asdf"));
    f(Arrays.asList(123));
}

}

Вывод:

strings
numbers

Вывод типа Java (что происходит когда вы вызываете статические, общие методы, такие как Array.asList), сложны и плохо определены в JLS. В этой статье от 2008 года содержится очень интересное описание некоторых проблем и способов их устранения:

Выведение типа Java не работает: как мы можем это исправить?

Eclipse может создать байт-код из этого:

public class Bla {
private static BigDecimal abc(List<BigDecimal> l) {
    return l.iterator().next().multiply(new BigDecimal(123));
}

private static String abc(List<String> l) {
    return l.iterator().next().length() + "";
}

public static void main(String[] args) {
    System.out.println(abc(Arrays.asList("asdf")));
    System.out.println(abc(Arrays.<BigDecimal>asList(new BigDecimal(123))));
}
}

Вывод:

4

15129