在Java中使用Deprecated方法或类是错误的吗？
我正在使用eclipse来开发一个Web应用程序。 就在今天，我通过更改JAR文件来更新我的struts版本。 我在某些地方得到警告，该方法已被弃用，但代码工作正常。
我想知道一些事情
-
在Java中使用Deprecated方法或类是错误的吗？
-
如果我不改变任何方法，并运行我的应用程序警告，那么会产生性能问题。
1.在Java中使用Deprecated方法或类是错误的吗？
从已弃用的定义 ：
注释@Deprecated的程序元素是程序员不鼓励使用的程序元素，通常是因为它是危险的，或者是因为存在更好的select。
该方法被保存在API中，用于在未指定的时间段内向后兼容，并且可能在将来的版本中被删除。 也就是说，不，这没有错 ，但是有一个更好的方法可以做到这一点，这对API的变化更加强大。
2.如果我没有改变任何方法并且运行我的应用程序，那么我会有什么警告，会不会造成任何性能问题？
最有可能没有。 它将继续按照弃用的方式工作。 API方法的合同不会改变。 如果一些内部数据结构改变，而采用新的，更好的方法，则可能会对性能产生影响，但这种情况不太可能发生。
Java API中最有趣的弃用方法是FontMetrics.getMaxDecent 。 弃用的原因：拼写错误。
已过时。 从JDK版本1.1.1开始，由getMaxDescent（）取代。
您仍然可以使用不推荐使用的代码而不改变性能，但是抛弃方法/类的全部意义在于让用户知道现在有更好的方法来使用它，而且在将来的版本中，可能会删除已弃用的代码。
术语
从官方的Sun词汇表：
弃用 ：指不再推荐的类，接口，构造函数，方法或字段，并可能在将来的版本中停止存在。
从何时何地开始弃用指南：
你可能听说过“自嘲的幽默”这个词，或者幽默说话者的重要性最小化。 不推荐使用的类或方法就是这样。 这不再重要。 事实上，你不应该再使用它，因为它已被取代，将来可能不复存在。
@Deprecated注释更进一步，并警告危险：
注释
@Deprecated的程序元素是程序员不鼓励使用的程序元素，通常是因为它是危险的 ，或者是因为存在更好的select。
参考
- java.sun.com词汇表
- 语言指南/如何以及何时弃用API
- 注释types不推荐使用的API
对还是错？
使用弃用方法是否正确的问题将需要在个人基础上进行检查。 下面是有效Java第2版中出现“已弃用”一词的所有引号：
第7项：避免终结器 ：声称保证终止的唯一方法是
System.runFinalizersOnExit及其邪恶的双Runtime.runFinalizersOnExit。 这些方法是致命的缺陷，已被弃用。第66项：同步对共享可变数据的访问 ：这些库提供了
Thread.stop方法，但是这种方法很久以前就被弃用了，因为它本质上是不安全的 – 它的使用会导致数据损坏。项目70：文档线程安全 ：
System.runFinalizersOnExit方法是线程敌对的，并已被弃用。Item 73：避免线程组 ：它们允许你一次性将特定的
Thread原语应用到一堆线程。 其中有几个基元已被弃用，其余的基本不常使用。 线程组已经过时。
所以，至less在所有上述方法中，使用它们显然是错误的，至less按照Josh Bloch的说法。
用其他方法，你必须单独考虑这些问题，并理解为什么他们被弃用，但一般来说，当反对的决定是合理的，倾向于倾向于错误而不是正确的继续使用它们。
相关问题
- 弃用和传统API之间的区别？
除了上述所有出色的响应，我发现还有一个原因是删除不推荐的API调用。
研究为什么一个调用被弃用我经常发现自己学习了关于Java / API /框架的有趣的事情。 通常有一个很好的理由，为什么一个方法被弃用，理解这些原因导致更深刻的见解。
所以从学习/成长的angular度来看，这也是一个值得的努力
它当然不会造成性能问题 – 在将来不推荐使用的方式，函数可能不再是库的一部分，所以您应该避免在新代码中使用它，并更改旧代码以停止使用它，所以有一天，当你升级struts并发现该function不再存在时，你不会遇到问题
你可能听说过“自嘲幽默”这个词。 这是幽默，最大限度地减less你的重要性。 不推荐使用的类或方法就是这样。 这不再重要。 事实上，它不应该再被使用，因为它将来可能会不复存在。
尽量避免它
这没有错，只是不推荐。 这通常意味着在这一点上有更好的做事方式，如果你使用新的改进方式，你会做得很好。 一些弃用的东西是非常危险的，应该完全避免。 新方法可以产生比已弃用的更好的性能，但事实并非总是如此。
- 一般来说不，使用
deprecated方法并不是绝对错误，只要你有一个好的应急计划，以避免这些方法从你使用的库中消失时出现任何问题。 有了Java API本身，这绝不会发生，但随着其他任何东西，这意味着它将被删除。 如果您特别计划不升级（ 尽pipe您最有可能应该从长远来看 ）软件的支持库，那么使用deprecated方法没有问题。 - 没有。
是的，这是错的。
弃用的方法或类将在未来版本的Java中删除，不应使用。 在每种情况下，都应该有一个替代scheme。 使用它。
有些情况下，您必须使用已弃用的类或方法才能实现项目目标。 在这种情况下，你真的别无select，只能使用它。 Java的未来版本可能会破坏该代码，但如果这是一个要求，你必须忍受。 这可能不是你第一次为了满足项目要求而做错了事情，而且肯定不会是最后一次。
当您升级到新版本的Java或其他库时，有时您使用的方法或类已被弃用。 不推荐使用的方法不被支持，但不应该产生意想不到的结果。 这并不意味着他们不会尽快切换你的代码。
弃用过程是为了确保作者有足够的时间将代码从旧的API更改为新的API。 利用这个时间。 尽快更改您的代码。
这是没有错的，但是一些被弃用的方法在未来版本的软件中被删除了，所以你最终可能会得到不工作的代码。
在Java中使用Deprecated方法或类是错误的吗？“
不是这样的错误，但它可以为您节省一些麻烦。 下面是一个非常不鼓励使用不推荐的方法的例子：
http://java.sun.com/j2se/1.4.2/docs/guide/misc/threadPrimitiveDeprecation.html
为什么不推荐使用Thread.stop？
因为它本质上是不安全的。 停止线程会导致它解锁所有已locking的监视器。 （当ThreadDeathexception传播到堆栈时，监视器被解锁。）如果之前由这些监视器保护的对象处于不一致状态，则其他线程现在可以以不一致的状态查看这些对象。 据称这些物体被损坏。 当线程操作受损对象时，可能导致任意行为。 这种行为可能是微妙的，难以察觉，或者可能是明显的。 与其他未经检查的exception不同，ThreadDeath静默地杀死线程; 因此，用户没有警告他的程序可能被损坏。 在发生实际损害后，腐败现象可能会随时出现，甚至在未来数小时甚至数天。
如果不改变任何方法，并运行我的应用程序，如果我有警告，它会产生任何性能问题。
在性能方面应该没有问题。 标准API旨在尊重一些向后兼容性，因此应用程序可以逐渐适应新版本的Java。
在Java中使用Deprecated方法或类是错误的吗？ 这不是“错误的”，仍在工作，但尽可能避免。
假设存在一个与方法相关的安全漏洞，开发人员认定这是一个devise缺陷。 所以他们可能会决定放弃这个方法，并引入新的方法。
所以，如果你仍然使用旧的方法，你有一个威胁。 所以要注意到弃用的原因，并检查它是如何影响你的。
如果不改变任何方法，并运行我的应用程序警告，我会有什么，它会造成任何性能问题。
如果弃用是由于性能问题造成的，那么您将面临性能问题，否则没有理由有这样的问题。 再次想指出的是，要知道贬值的原因。
当然不是 – 因为整个Java得到@Deprecated :-)只要Java持续，你可以随意使用它们。 无论如何不会注意到任何差异，除非它真的被破坏了。 含义 – 必须阅读并决定。
然而，在.Net中，当声明了某个东西的时候，即使你之前没有使用它，你也应该马上去阅读这个东西 – 你有50％的机会比replace更有效率和/或更容易使用:-)）
所以总的来说，这些天保持技术保守是相当有益的，但是你必须首先做好你的阅读工作。
在Java中，它被@Deprecated，在C＃中是[Obsolete]。
我想我更喜欢C＃的术语。 这只是意味着它已经过时了。 你仍然可以使用它，但可能有更好的方法。
这就像使用Windows 3.1而不是Windows 7，如果你相信Windows 3.1已经过时。 你仍然可以使用它，但未来的版本可能会有更好的function，而未来的版本可能会被支持 – 过时的版本将不会被支持。
Java的@deprecated也一样 – 你仍然可以使用这个方法，但是风险自担 – 将来可能有更好的select，甚至可能不被支持。
如果您使用的是不推荐使用的代码，则通常可以，只要您不必升级到更新的API，不build议使用的代码可能不存在。 我build议如果你看到使用不推荐的代码的东西，更新使用新的替代品（这通常在注释或Javadoc弃用的评论中指出）。
编辑：正如迈克尔所指出的，如果弃用的原因是由于function上的缺陷（或者因为function不应该存在），那么很明显，不应该使用弃用的代码。
我觉得弃用的方法意味着; 还有一种替代方法可用，比现有方法在所有方面都更好。 最好使用比现有的方法更好的方法。 为了向后兼容，旧的方法被弃用。
