Оператор алмаза (<>), введенный в Java 7, изначально поддерживал только выражения создания экземпляров конкретных классов, явно исключая анонимные внутренние классы. Когда разработчики пытались использовать конструкции, такие как new Comparable<String>() { ... }, компилятор отклонял вариант с оператором алмаза new Comparable<>() { ... }, поскольку анонимные классы могли вводить типы членов, которые ссылались на выводимые параметры типа, потенциально создавая ненадежные системы типов.
Основная проблема касалась неденотируемых типов. Анонимные классы могут объявлять методы или поля, типы которых зависят от параметров типов класса. Если компилятор определял сложный тип пересечения для оператора алмаза, как показано в проблемной ситуации, где анонимный класс объявляет void foo(Box<T> t) {}, тип T может представлять захваченный подстановочный знак, который невозможно выразить в исходном коде. Это создавало ситуацию, в которой API анонимного класса содержал типы, которые невозможно было называть или проверять на уровне исходного кода, что нарушало основное требование Java о том, что все типы в публичных API должны быть денотируемыми.
Java 9 решила эту проблему через JEP 213, реализовав анализ денотируемых типов. Компилятор теперь проверяет, что определенный тип для инициализации анонимного класса является денотируемым — т.е. может быть выражен с помощью синтаксиса типов Java. Следующий пример демонстрирует законное использование:
// Допустимо в Java 9+ Comparator<String> c = new Comparator<>() { @Override public int compare(String a, String b) { return a.length() - b.length(); } };
Если вывод приводит к сложному типу, включающему подстановочные знаки или пересечения, которые не могут быть обозначены, компилятор возвращается к требованию явных аргументов типа. Это обеспечивает безопасность типов, позволяя при этом лаконичный синтаксис для общих случаев.
В финансовой торговой платформе, созданной на Java 8, команда разработчиков поддерживала тысячи обработчиков событий. Эти обработчики использовали анонимные реализации Comparator<TradeEvent> и Predicate<MarketData> по всей системе сопоставления заказов, что требовало явных аргументов типа, создавая значительный визуальный шум во время код-ревью.
Команда рассматривала три подхода к уменьшению объема кода. Первый подход заключался в миграции всех анонимных классов в лямбда-выражения. Хотя это устраняло громоздкость в простых случаях, многие обработчики требовали частных вспомогательных методов или блоков обработки исключений, превышающих возможности лямбд. Это ограничение вынуждало неуклюжую реорганизацию в именованные внутренние классы, увеличивая количество классов и снижая локальность поведения.
Второй подход предполагал сохранение явных аргументов типа. Это сохраняло полную функциональность и работало с существующей инфраструктурой Java 8, но навлекало дополнительные затраты на обслуживание. Разработчики часто сталкивались с конфликтами при слиянии, изменяя сигнатуры типов, и избыточные объявления увеличивали когнитивную нагрузку во время сессий отладки.
Третий подход предложил обновление до Java 9, чтобы воспользоваться поддержкой оператора алмаза для анонимных классов. Оценив стоимость миграции относительно повышения производительности, команда выбрала обновление до Java 9, так как платформа требовала интеграции системы модулей Jigsaw в любом случае. Анализ денотируемых типов позволил им написать new Comparator<>() { public int compare(TradeEvent a, TradeEvent b) { ... } }, в то время как компилятор проверял, что TradeEvent представляет собой денотируемый тип.
Это изменение снизило среднюю длину определения обработчика с четырех до одного строки, устранив примерно 2400 строк избыточных объявлений типов. В результате конфликты при слиянии в модулях с широким использованием обобщений значительно уменьшились, так как потребность в синхронизации явных аргументов типов по веткам функций исчезла. Производительность разработки повысилась на пятнадцать процентов в последующие кварталы из-за уменьшения накладных расходов на рефакторинг.
Почему оператор алмаза не удается при выводе аргументов типа для обобщенных конструкторов в сырых типах?
При инстанцировании сырого класса, например new ArrayList()<>, оператор алмаза не может вывести аргументы типа, поскольку сырые типы полностью стирают информацию об обобщении. Компилятор рассматривает сырой тип как не имеющий параметров типа, что делает инференцию невозможной, поскольку сама сигнатура конструктора теряет параметризацию. Кандидаты часто путают это с предупреждениями о неконтролируемом преобразовании, но основная проблема заключается в полном стирании метаданных об обобщении в контексте сырых типов, а не только в неконтролируемых операция.
Как взаимодействие между поли выражениями и оператором алмаза влияет на разрешение перегрузки методов?
Оператор алмаза создает поли выражение, тип которого зависит от контекста присвоения. В контексте вызова метода, такого как process(new ArrayList<>()), компилятор должен определить целевой тип из формальных параметров метода перед завершением вывода типов. Это создает двунаправленную зависимость: применимость метода зависит от выводимого типа, но выводимый тип зависит от целевого типа. Компилятор разрешает это через этапы генерации ограничений и инкорпорации, потенциально выбирая разные перегрузки, чем это произошло бы с явными аргументами типа. Кандидаты часто упускают из виду, что разрешение перегрузки происходит до завершения полного вывода типов, что приводит к удивительным ошибкам компиляции, когда несколько перегрузок могут соответствовать.
Что отличает ограничение денотируемых типов от требования о реифицируемых типах при создании массивов?
Хотя оба ограничения предотвращают определенные операции с обобщениями, денотируемые типы (относящиеся к выводу оператора алмаза) требуют, чтобы типы могли быть выражены в исходном коде, в то время как реифицируемые типы (относящиеся к new T[10]) требуют информации о типе во время выполнения. Тип, такой как List<String>, является денотируемым, но не реифицируемым. Кандидаты часто смешивают эти ограничения, полагая, что неденотируемые типы представляют собой риски безопасности во время выполнения аналогично исключениям хранения массивов. На самом деле неденотируемые типы компрометируют выразительность типов на уровне исходного кода и согласованность API, в то время как нереифицируемые типы компрометируют безопасность типов во время выполнения. Понимание этого различия является ключевым при проектировании обобщенных API, которые должны оставаться совместимыми как с анонимными классами, так и с кодом на основе массивов.