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

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

Из определения устаревшего :

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

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

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

Скорее всего нет. Он будет продолжать работать, как и до прекращения поддержки. Контракт метода API не изменится. Если какая-то внутренняя структура данных изменится в пользу нового, лучшего метода, это может повлиять на производительность, но это маловероятно.

Самое забавное устаревание в Java API - это imo, это _ 1_. Причина устаревания: орфографическая ошибка.

Устарело. Начиная с версии 1.1.1 JDK, заменено на getMaxDescent ().

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

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

Из официального глоссария 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 примитивы к группе потоков одновременно. Некоторые из этих примитивов устарели, а остальные используются нечасто. [...] группы потоков устарели.

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

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

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

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

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

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

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

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

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

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

Постарайтесь избежать этого

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я чувствую, что устаревший метод означает; существует альтернативный метод, который во всех отношениях лучше существующего. Лучше использовать хороший метод, чем существующий старый метод. Для обратной совместимости старые методы оставлены как устаревшие.