Это неправильно использовать устаревшие методы или классы в Java?

Неправильно ли использовать устаревшие методы или классы в Java?"

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

http://java.sun.com/j2se/1.4.2/docs/guide/misc/threadPrimitiveDeprecation.html

Почему Thread.stop устарел?

Потому что он по своей сути небезопасен. Остановка потока приводит к тому, что он разблокирует все мониторы, которые он заблокировал. (Мониторы разблокируются по мере того, как исключение ThreadDeath распространяется вверх по стеку.) Если какой-либо из объектов ранее защищенных этими мониторами находились в противоречивом состоянии, другие потоки теперь могут просматривать эти объекты в противоречивом состоянии. Такие объекты считаются поврежденными. Когда потоки работают с поврежденными объектами, может возникнуть произвольное может привести к произвольному поведению. Это поведение может быть быть тонким и трудно обнаруживаемым, или оно может быть ярко выраженным. В отличие от других непроверенных исключений, ThreadDeath убивает потоки беззвучно; таким образом, пользователь не имеет предупреждения о том, что его программа может быть повреждена. Повреждение может проявиться проявиться в любое время после фактического повреждения, даже через несколько часов или дней будущем.

Что если не менять никаких методов и запустить мое приложение с предупреждениями, которые у меня есть, создаст ли это какие-либо проблемы с производительностью?

С точки зрения производительности проблем быть не должно. Стандартный API разработан с учетом некоторой обратной совместимости, поэтому приложения могут быть постепенно адаптированы к новым версиям Java.

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

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

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

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

Помимо всех замечательных ответов выше, я обнаружил, что есть еще одна причина для удаления устаревших вызовов API.

Исследуя, почему вызов устарел, я часто обнаруживаю, что узнаю интересные вещи о Java / API / Framework. Часто есть веская причина, по которой метод устарел, и понимание этих причин ведет к более глубокому пониманию.

Так что с точки зрения обучения / роста, это тоже стоит усилий

1. Как правило, нет, использование устаревших методов не является абсолютно неправильным, если у вас есть хороший план действий на случай непредвиденных обстоятельств, чтобы избежать каких-либо проблем, если / когда эти методы исчезнут из библиотеки, которую вы используете. С самим Java API этого никогда не происходит, но в любом другом случае это означает, что он будет удален. Если вы специально не планируете обновлять (, хотя, скорее всего, вам следует ) поддерживать библиотеки вашего программного обеспечения, тогда нет проблем с использованием устаревших методов .
2. Нет.

Терминология

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

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

Из руководства по поводу того, как и когда осуждать:

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

Аннотации @Deprecated пошли дальше и предупреждают об опасности:

Аннотированный @Deprecated программный элемент - это элемент, который программистам не рекомендуется использовать, обычно потому, что он опасно , или потому что существует лучшая альтернатива.

Ссылки

• java.sun.com Глоссарий
• Руководство по языку / Как и когда прекращать поддержку API
• API устаревшего типа аннотации

Правильно или неправильно?

Вопрос о том, правильно или неправильно использовать устаревшие методы, должен быть рассмотрен индивидуально основание. Вот ВСЕ кавычки, в которых слово "не рекомендуется" встречается в Эффективное 2-е издание Java :

Правило 7: Избегайте финализаторов : Единственное методы, которые утверждают, что гарантируют завершение, - это System.runFinalizersOnExit и его злой двойник Runtime.runFinalizersOnExit . Эти методы фатально ошибочны и устарели.

Правило 66: Синхронизация доступа к совместно используемым изменяемым данным : библиотеки предоставляют метод Thread.stop , но этот метод давно устарел, поскольку он изначально небезопасен - его использование может привести к повреждению данных.

Пункт 70: Безопасность потоков документов : Метод System.runFinalizersOnExit является враждебным к потокам и объявлен устаревшим.

Правило 73: Избегайте групп потоков : они позволяют применять определенные примитивы Thread к группе потоков одновременно. Некоторые из этих примитивов устарели, а остальные используются нечасто. [...] группы потоков устарели.

Таким образом, по крайней мере, со всеми вышеперечисленными методами их использование явно неправильно, по крайней мере, согласно Джошу Блоху.

При использовании других методов вам нужно будет рассматривать проблемы индивидуально и понимать ПОЧЕМУ они устарели, но, вообще говоря, когда решение отказаться от поддержки оправдано, оно будет склоняться к неправильному, чем право продолжать их использовать.

Связанные вопросы

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

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

Предположим, что существует уязвимость безопасности, связанная с методом, и разработчики определяют, что это недостаток дизайна. Поэтому они могут принять решение об отказе от метода и внедрении нового способа.

Так что если вы все еще используете старый метод, у вас есть угроза. Поэтому узнайте о причинах устаревания метода и проверьте, как это отразится на вас.

Что если не менять никаких методов и запустить мое приложение с предупреждениями, которые у меня есть, создаст ли это проблемы с производительностью?

Если обесценивание связано с проблемой производительности, то вы будете страдать от проблемы производительности, в противном случае нет причин для возникновения такой проблемы. Еще раз хотелось бы отметить, будьте осведомлены о причинах обесценивания.

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

Старайтесь избегать его

Да, это неправильно.

Устаревшие методы или классы будут удалены в будущих версиях Java и не должны использоваться. В каждом случае должна быть доступная альтернатива. Используйте это.

Есть несколько случаев, когда вам нужно использовать устаревший класс или метод, чтобы достичь цели проекта. В этом случае у вас действительно нет выбора, кроме как использовать его. Будущие версии Java могут сломать этот код, но если это требование, вам придется с этим смириться. Вероятно, это не первый раз, когда вам приходится делать что-то неправильно, чтобы выполнить требования проекта, и уж точно не последний.

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

Процесс устаревания необходим для того, чтобы у авторов было достаточно времени, чтобы изменить свой код со старого API на новый API. Используйте это время. Измените свой код как можно скорее.

В Java это @Deprecated, в C# — [Устарело].

Думаю, я предпочитаю терминологию C#. Это просто означает, что он устарел. Вы все еще можете использовать его, если хотите, но, вероятно, есть лучший способ.

Это похоже на использование Windows 3.1 вместо Windows 7, если вы считаете, что Windows 3.1 устарела. Вы все еще можете использовать его, но, вероятно, в будущей версии будут лучшие функции, плюс будущие версии, вероятно, будут поддерживаться - устаревшая версия не будет.

То же самое с @Deprecated в Java — вы все еще можете использовать этот метод, но на свой страх и риск — в будущем у него могут быть лучшие альтернативы, и он может даже не поддерживаться.

Если вы используете устаревший код, это обычно нормально, если вам не нужно обновлять API до более новой версии — устаревшего кода может там не быть. Я предлагаю, если вы видите что-то, что использует устаревший код, обновить, чтобы использовать более новые альтернативы (это обычно указывается в аннотации или в устаревшем комментарии Javadoc).

Редактировать: И, как указал Майкл, если причина устаревания связана с недостатком функциональности (или потому, что функциональность даже не должна существовать), то, очевидно, не следует использовать устаревший код.

Конечно, нет, поскольку вся Java становится @Deprecated :-) вы можете свободно использовать их, пока существует Java. В любом случае, никаких различий не заметишь, если только что-то действительно не сломано. Смысл - надо прочитать об этом, а потом решать.

Однако в .Net, когда что-то объявлено [Устаревшим], немедленно идите и прочитайте об этом, даже если вы никогда раньше этим не пользовались — у вас есть около 50% шансов, что это эффективнее и/или проще в использовании, чем замена :- ))

В общем, быть техно-консерватором в наши дни может быть весьма полезно, но сначала нужно заняться чтением.