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

Я использую Eclipse для разработки веб-приложения. Только сегодня я обновил свою версию Struts, изменив файл JAR. В некоторых местах я получаю предупреждения о том, что методы устарели, но код работает нормально.

Я хочу знать некоторые вещи

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

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

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

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

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

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

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

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

Самое смешное осуждение в Java API - это imo FontMetrics.getMaxDecent. Причина устаревания: орфографическая ошибка.

Устаревшее. Начиная с версии JDK 1.1.1, заменено 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. Нет.

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

Устаревшие методы или классы будут удалены в будущих версиях 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 устарела. Вы по-прежнему можете использовать его, но в будущей версии, вероятно, будут улучшенные функции, плюс будущие версии, вероятно, будут поддерживаться, а устаревшие - нет.

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

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

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

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

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

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

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