Почему не Collections.checkedMap и друзья используются чаще?

Недавно я наткнулся на Javadoc для семейства функций Collection.checkedMap для создания динамически типизированных представлений стандартных типов коллекций. Учитывая, что они добавляют еще один уровень безопасности поверх коллекций, которые диагностируют относительно распространенную ошибку программиста, я бы предположил, что они будут более популярными. По какой-то причине, однако, во всех крупных проектах Java, над которыми я работал, я не видел их однажды.

Мой вопрос таков: есть ли конкретная причина, по которой программисты Java не используют эти проверенные обертки чаще? Или это просто отсутствие пользы/недостатка знаний о их существовании?

EDIT. Чтобы уточнить мой вопрос, общие версии коллекций по-прежнему содержат небезопасные функции типа. Map containsKey, containsValue, remove и get работают, например, Object. Мой главный вопрос заключается в том, что, учитывая этот тип - небезопасность, почему больше людей не используют проверенные реализации для диагностики нарушений типа времени выполнения.

2 ответа

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

В результате использование этих методов действительно интересно в контексте дизайнеров API, которые не доверяют пользователям библиотеки, и хотят защитить самих себя или пользователей от пользователей, использующих карту ненадлежащим образом.

В этом случае: если ваш код компилируется без предупреждений о необработанном типе или любых непроверенных предупреждений о преобразовании/типе, вам гарантируется, что методы checked* не дают вам никакой пользы; они только врезаются во время выполнения.

Edit

Вы, похоже, заключаете, что, поскольку remove, get и т.д. работают на Object, они как-то небезопасны. Они не. Ни один из этих методов не сохранит свой операнд на карте, поэтому вы, безусловно, не ставите под угрозу безопасность типа самой карты. Эти методы принимают объект по одной основной причине: для обратной совместимости. Никогда не было никаких строгих требований, которые требовались бы для того, чтобы придерживаться одного и того же класса. Например, если экземпляр класса A и экземпляр класса B может быть каким-то образом равным друг другу, поместите a в карту, а затем вызов remove(b) должен удалить сопоставление a.

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


RETRACT: Неправильно следующее мнение. Есть несколько веских причин, помимо обратной совместимости, почему лучше, чтобы индекс поиска был любого типа.

Нет божественной причины, по которой эти методы должны принимать Object вместо E. В программах реального мира, если передается объект не-E, это почти наверняка ошибка приложения. В большинстве случаев API версии E будет лучше, чем версия Object. И я говорю, что Солнце допустило ошибку здесь. Не существует обратной совместимости, потому что общий API - это новый API.

К счастью, моя IDE (IntelliJ) предупредила бы меня, если я передам эти методы не-E. Статическая проверка была вытеснена за пределы того, что говорит спецификация языка и что делает компилятор.

licensed under cc by-sa 3.0 with attribution.