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