Я изучал устаревшие API в Java Collection Framework и узнал, что такие классы, как Vector и HashTable, были заменены на ArrayList и HashMap.
Тем не менее, они НЕ являются устаревшими и считаются устаревшими, хотя по существу, устаревание применяется к программным функциям, которые заменяются и которых следует избегать, поэтому я не уверен, когда API считается устаревшим, а когда он устарел.
Из официального глоссария Sun:
устаревание: относится к классу, интерфейсу, конструктору, методу или полю, которые больше не рекомендуются и могут перестать существовать в будущей версии.
Из руководства, как и когда отказаться от рекомендаций:
Возможно, вы слышали термин «самоуничижительный юмор» или «юмор», которые принижают важность говорящего. Устаревший класс или метод похож на это. Это уже не важно. Фактически, это настолько неважно, что вы больше не должны его использовать, поскольку он был заменен и может прекратить свое существование в будущем.
Аннотация @Deprecated пошла еще дальше и предупреждает об опасности:
Программный элемент, помеченный
@Deprecated, - это элемент, который программистам не рекомендуется использовать, обычно потому, что он опасен или потому что существует лучшая альтернатива.
Обратите внимание, что официальный глоссарий не определяет, что означает «наследие». По всей вероятности, это может быть термин, который использовал Джош Блох без точного определения. Однако всегда подразумевается, что унаследованный класс никогда не должен использоваться в новом коде и существует лучшая замена.
Возможно, старый код, использующий устаревший, но не устаревший класс, не требует никаких действий, поскольку, по крайней мере, на данный момент, они не рискуют перестать существовать в будущей версии.
Напротив, устаревание явно предупреждает, что они могут перестать существовать, поэтому следует принять меры для перехода на замену.
Для сравнения того, как эти термины используются в контексте, это цитаты из книги, где встречается слово не рекомендуется:
Правило 7. Избегайте финализаторов. Единственные методы, которые заявляют, что гарантируют завершение, - это
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.
Устаревание часто означает, что есть намерение удалить эту функциональность в какой-то момент в будущем, тогда как устаревшая версия просто подразумевает, что ее не следует использовать в новом коде, если это вообще возможно (хотя даже тогда может потребоваться по причинам взаимодействия).
Устарение означает, что это плохо и не должно использоваться - _ 1_ является ярким примером, поскольку он не создает правильные URL-адреса из файлов с пробелами в пути. Он просто не делает то, что должен, но поскольку существующий код может использовать обходные пути, которые сломаются, если ошибка будет исправлена.
Наследие просто означает, что он старый и есть способы сделать что-то, что в целом, но не обязательно, лучше. Vector - хороший пример - это List реализация, но в ней все еще есть некрасивая чушь, оставшаяся за дни до разработки API коллекций (т.е. List). Он также синхронизирован, что означает, что вы должны платить за синхронизацию даже при использовании его в однопоточном сценарии (за исключением некоторых ситуаций, когда виртуальная машина умна). ArrayList лучше, если вам нужна реализация списка с поддержкой массива, поскольку он несинхронизирован, а Collections.synchronizedList более гибок, если вам нужен синхронизированный список, поскольку это оболочка, которую можно использовать со всеми реализациями списков (связанные списки, списки из Arrays.asList(T...) и т. Д.). Однако, если вам действительно нужна синхронизированная реализация списка с поддержкой массива, тогда Vector подойдет.
java.util.concurrent, чем использовать Vector или _3 _... особенно Hashtable, поскольку ConcurrentHashMap допускает параллелизм, не требуя синхронизации карты.
- person Powerlord; 20.05.2010
synchronizedList и др. Обычно не то, что вам нужно.
- person gustafc; 20.05.2010
Я считаю, что у устаревшего кода просто есть более новые аналоги, которые лучше выполняют свою работу. Однако он будет продолжать получать исправления ошибок и другую поддержку. С другой стороны, устаревший код не поддерживается и не получает специальных исправлений ошибок.
Аннотация Устарело дает формальное определение устаревшего API. Я не думаю, что существует формальное определение устаревших классов. Оба фактически означают, что класс не должен использоваться в новом коде.
У меня есть предложение - устаревший относится к коду, который был написан в прошлом, устаревший относится к совету не использовать его больше. Вы все еще можете использовать устаревший API, но вы не можете писать устаревший код, потому что вы пишете его прямо сейчас. Просто ИМХО
