Я использую eclipse для разработки веб-приложения. Только сегодня я обновил версию struts, изменив файл JAR. Я получаю предупреждения в некоторых местах о том, что методы устарели, но код работает нормально.
Я хочу знать некоторые вещи
Неправильно ли использовать устаревшие методы или классы в Java?
Что делать, если я не изменяю какой-либо метод и не запускаю свое приложение с предупреждениями, которые у меня есть, создаст ли он какие-либо проблемы с производительностью.
1. Неправильно ли использовать устаревшие методы или классы в Java?
Программный элемент, аннотированный @Deprecated, является тем, что программистам не рекомендуется использовать, как правило, потому, что это опасно, или потому, что существует лучшая альтернатива.
Этот метод хранится в API для обратной совместимости в течение неопределенного периода времени и может удаляться в будущих выпусках. То есть нет, это не так, но есть лучший способ сделать это, что более устойчиво против изменений API.
2. Что делать, если я не изменяю какой-либо метод и не запускаю мое приложение с предупреждениями, которые у меня есть, создаст ли он какие-либо проблемы с производительностью.
Скорее всего нет. Он будет по-прежнему работать по-прежнему без устали. Контракт метода API не изменится. Если какая-то внутренняя структура данных изменится в пользу нового, лучшего метода, это может повлиять на производительность, но это маловероятно.
самое забавное изъятие в Java API - это imo, FontMetrics.getMaxDecent. Причина устаревания: ошибка орфографии.
Устаревшие. Начиная с версии 1.1.1 JDK, заменяется на getMaxDescent().
Вы все равно можете использовать устаревший код без изменения производительности, но вся суть обесценивания метода/класса заключается в том, чтобы пользователи знали, что теперь есть лучший способ его использования, и что в будущей версии устаревший код, скорее всего, удаляться.
Из официального глоссария Sun:
deprecation. Относится к классу, интерфейсу, конструктору, методу или полю, который больше не рекомендуется, и может перестать существовать в будущей версии.
Из руководства how-and-when для отказа от руководства:
Возможно, вы слышали термин "самоуничижительный юмор" или юмор, который минимизирует важность оратора. Устаревший класс или метод подобны этому. Это уже не важно. На самом деле так важно, что вы больше не должны его использовать, поскольку он был заменен и может перестать существовать в будущем.
Аннотация @Deprecated шла дальше и предупреждала об опасности:
Программный элемент, аннотированный
@Deprecated, является тем, что программистам не рекомендуется использовать, как правило, потому, что это опасно, или потому, что существует лучшая альтернатива.
Вопрос о том, правильно или неправильно использовать устаревшие методы, должен быть рассмотрен на индивидуальной основе. Ниже приведено ВСЕ кавычки, в которых слово "устаревшее" появляется в "Эффективном Java 2nd Edition":
Пункт 7: Избегайте финализаторов. Единственными методами, которые утверждают, что они гарантируют завершение, являются
System.runFinalizersOnExitи его злой близнецRuntime.runFinalizersOnExit. Эти методы смертельно ошибочны и устарели.Пункт 66: Синхронизация доступа к общим изменяемым данным. Библиотеки предоставляют метод
Thread.stop, но этот метод давно устарел, поскольку он по своей сути небезопасен - его использование может привести к повреждению данных.Пункт 70: Безопасность потока документов. Метод
System.runFinalizersOnExitявляется поточно-враждебным и устарел.Пункт 73: Избегайте групп потоков. Они позволяют применять некоторые примитивы
Threadк кучке потоков одновременно. Некоторые из этих примитивов устарели, а остальные редко используются. [...] группы потоков устарели.
Итак, по крайней мере, со всеми вышеперечисленными методами, это явно неправильно использовать их, по крайней мере, согласно Джошу Блоху.
С помощью других методов вам нужно будет рассматривать проблемы индивидуально и понимать ПОЧЕМУ, они были устаревшими, но, вообще говоря, когда решение об отказе оправдано, оно будет склоняться против неправильного чем право продолжать их использование.
Помимо всех отличных ответов выше, я обнаружил, что есть еще одна причина для удаления устаревших вызовов API.
Изучайте, почему вызов устарел. Я часто нахожу, что изучаю интересные вещи о Java/API/Framework. Часто есть веская причина, почему метод устаревает, и понимание этих причин приводит к более глубокому пониманию.
Таким образом, с точки зрения обучения/роста, это также стоит усилий
Это, безусловно, не создает проблемы с производительностью - устаревшее означает, что в будущем, скорее всего, функция больше не будет частью библиотеки, поэтому вам следует избегать использования ее в новом коде и измените свой старый код, чтобы прекратить его использовать, поэтому однажды вы не сталкиваетесь с проблемами при обновлении расположений и обнаружите, что функция больше не присутствует.
Возможно, вы слышали термин "самоуничижительный юмор". Это юмор, который минимизирует вашу важность. Устаревший класс или метод подобны этому. Это уже не важно. На самом деле так важно, что его больше нельзя использовать вообще, поскольку оно, вероятно, перестанет существовать в будущем.
Попробуйте избежать этого
Это не так, просто не рекомендуется. Обычно это означает, что на данный момент есть лучший способ сделать что-то, и вы добьетесь успеха, если будете использовать новый улучшенный способ. Некоторые устаревшие вещи действительно опасны и их следует избегать вообще. Новый способ может дать лучшую производительность, чем устаревший, но это не всегда так.
deprecated, если у вас есть хороший план на случай непредвиденных обстоятельств, чтобы избежать каких-либо проблем, если/когда эти методы исчезнут из библиотеки, которую вы используете. С самим Java API это никогда не происходит, но с чем-либо еще это означает, что он будет удален. Если вы планируете не модернизировать (хотя, скорее всего, в конечном итоге, скорее всего, придется), то ваши программные библиотеки, поддерживающие программное обеспечение, тогда нет проблем с использованием методов deprecated.Да, это неправильно.
Устаревшие методы или классы будут удалены в будущих версиях Java и не должны использоваться. В каждом случае должна быть доступна альтернатива. Используйте это.
Есть несколько случаев, когда вам нужно использовать устаревший класс или метод для достижения цели проекта. В этом случае у вас действительно нет выбора, кроме как использовать его. Будущие версии Java могут нарушить этот код, но если это требование, вам нужно жить с этим. Вероятно, это не первый случай, когда вам нужно было сделать что-то неправильно, чтобы соответствовать требованиям проекта, и это, безусловно, не будет последним.
При обновлении до новой версии Java или какой-либо другой библиотеки иногда метод или класс, которые вы использовали, устаревают. Устаревшие методы не поддерживаются, но не должны давать неожиданных результатов. Это не значит, что они не будут, тем не менее, переключать ваш код как можно скорее.
Процесс устаревания заключается в том, чтобы у авторов было достаточно времени для изменения своего кода с старого API на новый API. Используйте это время. Измените свой код на ASAP.
Это не так, но некоторые из устаревших методов удаляются в будущих версиях программного обеспечения, поэтому вы, возможно, закончите с неработающим кодом.
Неправильно ли использовать устаревшие методы или классы в Java? "
Не так плохо, но это может сэкономить вам неприятности. Вот пример, в котором настоятельно не рекомендуется использовать устаревший метод:
http://java.sun.com/j2se/1.4.2/docs/guide/misc/threadPrimitiveDeprecation.html
Почему Thread.stop не рекомендуется?
Потому что это по своей сути небезопасно. Остановка потока заставляет его разблокировать все мониторы, которые он заблокировал. (Мониторы разблокированы как Исключение ThreadDeath распространяется вверх стек.) Если какой-либо из объектов ранее защищенные этими мониторами были в противоречивом состоянии, другие теперь потоки могут просматривать эти объекты в несогласованное состояние. Такие объекты как говорят, повреждены. Когда потоки работать на поврежденных объектах, произвольно поведение может привести. Такое поведение может быть тонким и трудно обнаружить, или это может быть выражено. в отличие от других исключенные исключения, ThreadDeath убивает нитки молча; таким образом, пользователь не предупреждает о том, что его программа может быть поврежден. Коррупция может проявляться себя в любое время после фактического повреждение, даже часы или дни в будущее.
Что делать, если не изменить какой-либо метод и запустить мое приложение с предупреждениями, которые у меня есть, приведет ли он к какой-либо проблеме с производительностью.
Не должно быть никаких проблем с точки зрения производительности. Стандартный API разработан с учетом некоторой обратной совместимости, поэтому приложения могут постепенно адаптироваться к более новым версиям Java.
Неправильно ли использовать устаревшие методы или классы в Java? Это не "неправильно", все еще работает, но избегайте его как можно больше.
Предположим, что существует уязвимость безопасности, связанная с методом, и разработчики определяют, что это ошибка дизайна. Поэтому они могут решить отказаться от метода и ввести новый способ.
Итак, если вы все еще используете старый метод, у вас есть угроза. Поэтому имейте в виду причину устаревания и проверьте, как это влияет на вас.
Что делать, если не изменить какой-либо метод и запустить мое приложение с предупреждениями, которые у меня есть, приведет к какой-либо проблеме с производительностью.
Если из-за проблемы с производительностью возникает ошибка, тогда вы будете испытывать проблемы с производительностью, иначе нет причин для возникновения такой проблемы. Опять же хотелось бы отметить, помните о причине устаревания.
В Java это @Deprecated, в С# это [Устаревшее].
Я думаю, что предпочитаю терминологию С#. Это просто означает, что он устарел. Вы все равно можете использовать его, если хотите, но, вероятно, лучший способ.
Это похоже на использование Windows 3.1 вместо Windows 7, если вы считаете, что Windows 3.1 устарела. Вы все еще можете использовать его, но, вероятно, в будущей версии, возможно, есть лучшие функции, плюс будущие версии, вероятно, будут поддерживаться - устаревшего не будет.
То же самое для Java @Deprecated - вы все равно можете использовать этот метод, но на свой страх и риск - в будущем он может иметь лучшие альтернативы и даже не поддерживается.
Если вы используете устаревший код, он обычно прекрасен, если вам не нужно обновляться до более нового API - устаревший код может там не существовать. Я предлагаю, если вы видите что-то, использующее устаревший код, для обновления, чтобы использовать более новые альтернативы (обычно это указывается в аннотации или в недостоверном комментарии Javadoc).
Изменить: И как указал Майкл, если причина для устаревания связана с недостатком функциональности (или потому, что функциональность не существует даже), то, очевидно, не следует использовать устаревший код.
Конечно, нет - поскольку вся Java получает @Deprecated:-), вы можете свободно использовать их до тех пор, пока Java длится. Не собираюсь замечать никаких различий, если только это не портит. Значение - нужно прочитать об этом, а затем решить.
В .Net, однако, когда что-то объявлено [Устаревшим], немедленно и сразу прочитайте об этом, даже если вы никогда не использовали его раньше - у вас есть 50% вероятность того, что он будет более эффективным и/или более простым в использовании, чем замена: ))
В общем, в наши дни может быть очень полезно быть техноконсервативным, но сначала вам нужно заниматься чтением.
Я считаю, что устаревший метод означает; существует альтернативный метод ive, который лучше во всех аспектах, чем существующий метод. Лучше использовать хороший метод, чем существующий старый метод. Для обратной совместимости старые методы остаются устаревшими.