在Java中使用不推荐使用的方法或类是错误的吗？

我正在使用eclipse开发Web应用程序。就在今天，我已经通过更改JAR文件更新了我的struts版本。我在某些地方收到不赞成使用方法的警告，但是代码可以正常工作。

我想知道一些事情

1. 在Java中使用不推荐使用的方法或类是错误的吗？

2. 如果我不更改任何方法并在有警告的情况下运行我的应用程序，将会造成性能问题。

1.在Java中使用不赞成使用的方法或类是错误的吗？

从弃用的定义：

注释为@Deprecated的程序元素是不鼓励程序员使用的元素，通常是因为这样做很危险，或者因为存在更好的替代方法。

该方法在API中保留了一段时间，以便在向后兼容的过程中保持未指定的时间，并且将来可能会删除该方法。就是说，不，这没有错，但是有一种更好的方法可以做到这一点，它对API更改更健壮。

2.如果我不更改任何方法并在有警告的情况下运行我的应用程序，将会造成性能问题。

很可能没有。它会像弃用前一样继续工作。API方法的合同不会更改。如果某些内部数据结构发生变化，而采用一种新的更好的方法，则可能会对性能产生影响，但这种可能性很小。

在最有趣的弃用 Java API中，是海事组织，FontMetrics.getMaxDecent。弃用原因：拼写错误。

不推荐使用。从JDK版本1.1.1开始，由getMaxDescent（）取代。

您仍然可以在不改变性能的情况下使用不推荐使用的代码，但是不推荐使用方法/类的全部目的是让用户知道现在有一种更好的使用方法/类，并且在将来的版本中，不推荐使用的代码可能会被删除。

术语

从Sun官方词汇表中：

弃用：指不再推荐的类，接口，构造函数，方法或字段，并且在以后的版本中可能不再存在。

从何时弃用指南：

您可能已经听说过“自嘲的幽默”一词，或使演讲者的重要性降至最低的幽默。弃用的类或方法就是这样。它不再重要。实际上，它是如此不重要，以致您不再应该使用它，因为它已被取代，并且将来可能不再存在。

该@Deprecated注释更进一步，并警告危险：

注释的程序元素@Deprecated是不鼓励程序员使用的元素，通常是因为这样做很危险，或者因为存在更好的替代方法。

参考文献

• java.sun.com词汇表
• 语言指南/如何以及何时弃用API
• 注释类型弃用的API

对还是错？

使用不赞成使用的方法是对还是错的问题必须逐个检查。这是在有效Java 2nd Edition中出现“不赞成”一词的所有引号：

项目7：避免终结器：声称保证终结的唯一方法是System.runFinalizersOnExit及其邪恶的孪生兄弟Runtime.runFinalizersOnExit。这些方法存在致命缺陷，已被弃用。

项目66：同步访问共享的可变数据：库提供了该Thread.stop方法，但是很久以前不赞成使用此方法，因为它本质上是不安全的 -使用该方法可能会导致数据损坏。

项目70：文档线程安全性：该System.runFinalizersOnExit方法是线程恶意的，已被弃用。

项目73：避免线程组：它们使您可以一次将某些Thread原语应用于一堆线程。这些原语中有几个已被弃用，其余的则很少使用。线程组已过时。

因此，至少对于所有上述方法，至少根据Josh Bloch的说法，使用它们显然是错误的。

使用其他方法时，您必须单独考虑问题，并理解为什么不建议使用这些问题，但总的来说，如果决定弃用是合理的，则倾向于倾向于错误而不是继续使用它们。

相关问题

• 不推荐使用的API和旧版API之间的区别？

除了上述所有出色的响应之外，我发现还有另一个原因可以删除不赞成使用的API调用。

在研究为什么不赞成使用电话的过程中，我经常发现自己对Java / API /框架感兴趣。通常有一个很好的理由为什么不赞成使用一种方法，而理解这些原因可以带来更深刻的见解。

因此，从学习/成长的角度来看，这也是值得的

它当然不会造成性能问题- 不建议使用，这意味着将来该函数可能不再是该库的一部分，因此您应避免在新代码中使用它，并更改旧代码以停止使用它，因此升级struts并发现该功能不再存在的一天，您不会遇到任何问题

没错，只是不推荐。通常，这意味着到现在为止，有一种更好的做事方法，如果您使用改进的新方法，您会做得更好。一些过时的东西确实很危险，应该完全避免。新方法可以产生比已弃用的方法更好的性能，但并非总是如此。

您可能听说过“自嘲的幽默”一词。那是幽默，使您的重要性降至最低。弃用的类或方法就是这样。它不再重要。实际上，它是如此不重要，以至于根本不再使用它，因为它将来可能会不复存在。

尽量避免

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 3.1而不是Windows 7。您仍然可以使用它，但是将来的版本中可能会有更好的功能，而且将来的版本可能会受支持-不会过时的版本。

与Java的@Deprecated相同-您仍然可以使用该方法，但后果自负-将来，它可能会有更好的替代方法，甚至可能不受支持。

如果您使用的是不推荐使用的代码，那么通常就可以，只要您不必升级到较新的API-那里可能不存在不推荐使用的代码。我建议如果您看到使用不赞成使用的代码的东西，以进行更新以使用较新的替代方法（通常在注释或Javadoc不赞成使用的注释中指出）。

编辑：正如迈克尔所指出的那样，如果过时的原因是由于功能中的缺陷（或者因为该功能甚至不应该存在），那么显然，不应使用过时的代码。

当然不是-因为整个Java都已@Deprecated :-)，只要Java持续使用，您就可以随意使用它们。无论如何都不会注意到任何差异，除非它确实被破坏了。含义-必须先阅读一下然后再决定。

但是，在.Net中，如果某项声明为[过时]，则即使您从未使用过，也要立即阅读它-与替换相比，它有50％的机会更有效率和/或更容易使用:-)）

因此，总的来说，这几天保持技术保守可能会非常有益，但是您必须先做好阅读工作。

我觉得不推荐使用的方法意味着什么；有一种可供选择的替代方法，在所有方面都比现有方法更好。比现有的旧方法更好地使用好的方法。为了向后兼容，不建议使用旧方法。