Это действительно Java?

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

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

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

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

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

--- Оригинальный пост ниже ---

в то время как компиляторы могут допустившие это, ответа до сих пор нет.

стирание превратит как 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.

Ну, если я правильно понимаю пункт три в первом списке из раздела 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;
    }
...

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

это действительно ВАЗ на спецификация.

подпись метода m1 - Это подподписью подпись метод m2 если

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

• подпись m1 Это то же самое, что и стирание подписи m2.

так что это не подсигналы друг друга, потому что стирание List<String> не List<Integer> и наоборот.

две сигнатуры метода m1 и m2 are переопределить-эквивалент эквивалентность или m1 - Это подподписью m2 или m2 это подподписью m1.

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

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

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

также работает (с 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);
    }

}

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

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

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

вывод типа 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

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

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