Краткий ответ

Java отвергает такой класс, потому что возвращаемый тип не входит в сигнатуру метода. Для различения методов при перегрузке учитываются имя, типовые параметры и типы формальных параметров, но не результат. Поэтому два метода с одинаковым именем и параметрами считаются одной и той же сигнатурой.

Исторический контекст

Языковая модель Java разделяет выбор метода и обработку результата его вызова. Перегрузка должна определяться по аргументам, доступным в месте вызова, а не по тому, куда вызывающий код собирается поместить результат.

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

Постановка проблемы

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

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

class Converter {
    String convert(int value) {
        return String.valueOf(value);
    }

    // Ошибка компиляции: такая сигнатура уже объявлена.
    // Integer convert(int value) {
    //     return value;
    // }
}

Подробное решение

Сигнатура метода в Java определяется его именем и типами формальных параметров; параметры типа также участвуют в определении сигнатуры. Возвращаемый тип, список checked-исключений и модификаторы доступа метод не различают.

Поэтому изменение только результата не создаёт перегрузку. Нельзя объявить одновременно convert(int) с результатом String и convert(int) с результатом Integer.

Ожидаемый тип результата может участвовать в проверке совместимости уже выбранного метода, а в отдельных случаях — в выводе типов обобщённого вызова. Но он не превращает два метода с одинаковыми параметрами в допустимые перегрузки.

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

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

Ситуация из практики

В библиотеке преобразований понадобились операции, возвращающие текстовое представление объекта и числовой идентификатор. Попытка назвать обе операции convert с одинаковым входным типом не компилировалась, поскольку результат не участвует в сигнатуре.

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

Были выбраны разные смысловые имена. В результате вызовы стали однозначными без приведений типов и специальных соглашений о значении лишнего параметра; API оказался проще для автодополнения и сопровождения.

Что кандидаты часто упускают

Может ли контекст присваивания выбрать один из двух методов, если они отличаются только возвращаемым типом?

Нет. Такие методы нельзя одновременно объявить в Java-классе, поэтому до анализа присваивания дело не дойдёт. Контекстный тип может проверить совместимость результата или участвовать в выводе параметров обобщённого метода, но не заменяет сигнатуру и не выбирает между методами, запрещёнными правилами языка.

Входит ли список checked-исключений в сигнатуру метода?

Нет. Методы с одинаковыми именем и типами параметров нельзя различить только через throws. Это важно, потому что обработка исключений происходит после выбора метода: компилятор проверяет допустимость исключений вызванного метода, но не использует их список для перегрузки.

Почему в байткоде иногда видны методы, которые невозможно объявить в Java-исходнике?

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

Однако Java-правила исходного кода строже: возвращаемый тип не является частью сигнатуры метода. Поэтому наличие подобных методов в байткоде не означает, что их можно безопасно объявить вручную или использовать как обычные перегрузки Java.