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

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

Я хочу знать кое-что

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

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

16 ответов

Решение

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

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

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

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

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

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


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

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

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

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

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

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

От того, как и когда отказаться от руководства:

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

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

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

Рекомендации


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

Вопрос о том, правильно или неправильно использовать устаревшие методы, должен быть рассмотрен на индивидуальной основе. Вот ВСЕ цитаты, где слово "устарел" появляется в Effective Java 2nd Edition:

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

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

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

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

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

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

Смежные вопросы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

Другие вопросы по тегам