Разница между устаревшим и устаревшим API?
Я изучал устаревшие API в Java Collection Framework и я узнал, что такие классы, как Vector а также HashTable были заменены ArrayList а также HashMap,
Тем не менее, они НЕ устаревают и считаются устаревшими, когда по сути устаревание применяется к программным функциям, которые заменены, и их следует избегать, поэтому я не уверен, когда API считается устаревшим, а когда - устаревшим.
7 ответов
Из официального глоссария Sun:
не рекомендуется: Относится к классу, интерфейсу, конструктору, методу или полю, которые больше не рекомендуются и могут прекратиться в будущей версии.
От того, как и когда отказаться от руководства:
Возможно, вы слышали термин "самоуничижительный юмор" или юмор, который сводит к минимуму важность говорящего. Устаревший класс или метод подобен этому. Это больше не важно. На самом деле это настолько неважно, что вы больше не должны его использовать, поскольку оно было заменено и может прекратиться в будущем.
@Deprecated аннотация пошла еще дальше и предупреждает об опасности:
Аннотированный элемент программы
@Deprecatedэто тот, который программистам не рекомендуется использовать, как правило, потому что это опасно, или потому что существует лучшая альтернатива.
Рекомендации
- java.sun.com Глоссарий
- Руководство по языку / Как и когда следует устаревать API
- Тип аннотации Устаревший API
Обратите внимание, что официальный глоссарий не определяет, что означает "наследие". По всей вероятности, это может быть термин, который Джош Блох использовал без точного определения. Однако всегда подразумевается, что устаревший класс никогда не должен использоваться в новом коде, и существует лучшая замена.
Возможно, старый код, использующий унаследованный, но не устаревший класс, не требует никаких действий, поскольку, по крайней мере, на данный момент им не грозит прекращение существования в будущей версии.
Напротив, устаревание явно предупреждает, что они могут прекратить существовать, поэтому необходимо принять меры для перехода на замену.
Цитаты из Effective Java 2nd Edition
Для сравнения того, как эти термины используются в контексте, это цитаты из книги, где появляется слово "устарел":
Пункт 7: Избегайте финализаторов. Единственные методы, которые гарантируют завершение
System.runFinalizersOnExitи его злой близнецRuntime.runFinalizersOnExit, Эти методы смертельно ошибочны и устарели.Пункт 66: Синхронизировать доступ к общим изменяемым данным: библиотеки предоставляют
Thread.stopметод, но этот метод давно устарел, потому что он по сути небезопасен - его использование может привести к повреждению данных.Пункт 70: Безопасность документов:
System.runFinalizersOnExitМетод является враждебным по отношению к потокам и был объявлен устаревшим.Пункт 73: Избегайте групп нитей: они позволяют вам применять определенные
Threadпримитивы к куче потоков сразу. Некоторые из этих примитивов устарели, а остальные используются нечасто. [...] группы потоков устарели.
Напротив, это цитаты, где появляется слово "наследие":
Пункт 23: Не используйте необработанные типы в новом коде: они предоставляются для совместимости и взаимодействия с устаревшим кодом, который предшествовал введению обобщений.
Пункт 25: Предпочитайте списки массивам: Erasure - это то, что позволяет универсальным типам свободно взаимодействовать с устаревшим кодом, который не использует обобщенные типы.
Пункт 29: Рассмотрим безопасные для типов гетерогенные контейнеры. Эти оболочки полезны для отслеживания, кто добавляет неправильно набранный элемент в коллекцию в приложении, которое смешивает общий и устаревший код.
Правило 54: Используйте нативные методы разумно: они предоставляют доступ к библиотекам унаследованного кода, что, в свою очередь, может обеспечить доступ к унаследованным данным. [...] Также допустимо использовать нативные методы для доступа к унаследованному коду. [...] Если вы должны использовать собственные методы для доступа к низкоуровневым ресурсам или устаревшим библиотекам, используйте как можно меньше собственного кода и тщательно его протестируйте.
Пункт 69: Предпочитайте утилиты параллелизма ждать и уведомлять: Хотя вы всегда должны использовать утилиты параллелизма вместо
waitа такжеnotifyвам, возможно, придется поддерживать устаревший код, который используетwaitа такжеnotify,
Эти цитаты не были тщательно отобраны: это ВСЕ случаи, когда в книге появляются слова "устарел" и "наследие". Сообщение Блоха здесь ясно:
- Устаревшие методы, например
Thread.stop, опасны и никогда не должны использоваться вообще. - С другой стороны, например
wait/notifyможет оставаться в устаревшем коде, но не должен использоваться в новом коде.
Мое собственное субъективное мнение
Моя интерпретация заключается в том, что унижение чего-либо - это признание того, что это ошибка, и с самого начала она никогда не была хорошей. С другой стороны, классификация того, что что-то является наследием, означает признание того, что оно было достаточно хорошим в прошлом, но оно выполнило свою задачу и больше не является достаточно хорошим для настоящего и будущего.
Распространенным толкованием является то, что "Устаревшее" означает, что оно будет удалено в ближайшем будущем, а "Наследие" означает, что оно останется для обратной совместимости или по другим причинам.
Оба означают, что они не должны использоваться новым кодом.
В случае JDK даже устаревший код останется, поскольку обратная совместимость очень важна для Java JDK.
Устаревание часто означает, что в какой-то момент в будущем есть намерение удалить функциональность, тогда как устаревшее просто подразумевает, что его не следует использовать в новом коде, если это вообще возможно (хотя может даже понадобиться по причинам взаимодействия).
Моя интерпретация заключается в том, что код Legacy просто имеет более новые аналоги, которые делают работу лучше. Однако он продолжит получать исправления ошибок и другую поддержку. С другой стороны, устаревший код не поддерживается и не будет получать исправления ошибок.
Устаревание означает, что это плохо и не должно использоваться - File.toURL() это яркий пример, так как он не создает правильные URL из файлов с пробелами в пути. Он просто не делает то, что должен, но так как существующий код может использовать обходные пути, которые сломаются, если ошибка будет исправлена
Наследие просто означает, что оно старое, и есть способы сделать что-то, что, как правило, но не обязательно, лучше. Vector хороший пример - это List реализация, но он все еще получил некрасивую чушь за несколько дней до API коллекций (т.е. List) был разработан. Он также синхронизирован, что означает, что вы должны платить за синхронизацию, даже если используете его в однопоточном сценарии (за исключением некоторых ситуаций, когда виртуальная машина умна). ArrayList лучше, если вы хотите реализацию списка с массивом, поскольку он не синхронизирован, и Collections.synchronizedList является более гибким, когда вы хотите синхронизированный список, так как это оболочка, которая может использоваться со всеми реализациями списков (связанные списки, списки из Arrays.asList(T...), так далее). Однако, если вам действительно нужна реализация синхронизированного списка с массивами, тогда Vector Это хорошо.
Устаревшая аннотация дает формальное определение устаревшего API. Я не думаю, что существует формальное определение унаследованных классов. Оба факта означают, что класс не должен использоваться в новом коде.
У меня есть предложение - наследие относится к коду, который был написан в прошлом, устарел относится к совету не использовать его больше. Вы все еще можете использовать устаревший API, но вы не можете писать устаревший код, потому что вы пишете его прямо сейчас. Просто ИМХО