Разница между устаревшим и устаревшим API?

Ответ 1

Из официального глоссария Sun:

deprecation. Относится к классу, интерфейсу, конструктору, методу или полю, который больше не рекомендуется, и может перестать существовать в будущей версии.

Из руководства how-and-when для отказа от руководства:

Возможно, вы слышали термин "самоуничижительный юмор" или юмор, который минимизирует важность оратора. Устаревший класс или метод подобны этому. Это уже не важно. На самом деле так важно, что вы больше не должны его использовать, поскольку он был заменен и может перестать существовать в будущем.

Аннотация @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 - это то, что позволяет универсальным типам свободно взаимодействовать с устаревшим кодом, который не использует generics.

Пункт 29: Рассмотрите типы гетерогенных контейнеров. Эти обертки полезны для отслеживания того, кто добавляет неверно типизированный элемент в коллекцию в приложении, которое смешивает общий и устаревший код.

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

Пункт 69: Предпочитают concurrency утилиты ждать и уведомлять. Хотя вы всегда должны использовать утилиты concurrency, предпочитая wait и notify, возможно, вам придется поддерживать устаревшие код, который использует wait и notify.

Эти цитаты не были тщательно отобраны: это ВСЕ экземпляры, в которых в книге появляются слова "устаревшие" и "устаревшие". Сообщение Блоха ясно здесь:

• Устаревшие методы, например. Thread.stop, являются опасными и никогда не должны использоваться вообще.
• С другой стороны, например, wait/notify может оставаться в устаревшем коде, но не должен использоваться в новом коде.

Мое собственное субъективное мнение

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

Ответ 2

Общей интерпретацией является то, что устаревшее означает, что оно будет удалено в ближайшем будущем, а Legacy означает, что оно останется для обратной совместимости или по другим причинам.

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

В случае JDK даже устаревший код останется, так как обратная совместимость очень важна для Java JDK.

Ответ 3

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

Ответ 4

Аннотация Deprecated дает формальное определение устаревшего API. Я не думаю, что существует формальное определение для устаревших классов. Оба фактически означают, что класс не должен использоваться в новом коде.

Ответ 5

У меня есть предложение - наследие относится к коду, который был написан в прошлом, устаревший относится к совету не использовать его больше. Вы все равно можете использовать устаревший api, но вы не можете писать устаревший код, потому что вы пишете его прямо сейчас. Просто IMHO

Ответ 6

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

Наследие просто означает, что оно старое, и есть способы сделать что-то, что обычно, но не обязательно, лучше. Vector - хороший пример - это реализация List, но у нее все еще появилось некоторое уродливое дерьмо за несколько дней до того, как был разработан API коллекций (т.е. List). Он также синхронизируется, что означает, что вы должны платить плату за синхронизацию даже при использовании ее в однопоточном сценарии (за исключением случаев, когда виртуальная машина умна). ArrayList лучше, если вам нужна реализация списка с поддержкой массива, поскольку она несинхронизирована, а Collections.synchronizedList более гибкая, если вам нужен синхронизированный список, поскольку это оболочка, которая может использоваться со всеми реализациями списков (связанные списки, списки из Arrays.asList(T...) и т.д.). Однако, если вам действительно нужна синхронизированная реализация с поддержкой массива, тогда Vector отлично.

Ответ 7

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