在 Java 中使用弃用的方法或类是错误的吗？

小开

没错，只是不推荐。这通常意味着，在这一点上，有一个更好的方式做事情，你会做好，如果你使用新的改进的方式。有些不被推崇的东西真的很危险，应该完全避免。新的方法可以产生比已废弃的方法更好的性能，但情况并非总是如此。

小开

它当然不会造成性能问题—— 不赞成意味着将来函数可能不再是库的一部分，所以你应该避免在新代码中使用它，改变你的旧代码以停止使用它，这样当你升级 struts 并发现函数不再存在时，你就不会遇到问题

小开

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

小开

最佳答案

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

来自废弃物的定义:

带注释@Dedecated 的程序元素是不鼓励程序员使用的元素，通常是因为它很危险，或者因为存在更好的替代方案。

这个方法会在原料药向下兼容内保存一段未指明的时间，日后可能会被移除。也就是说，不，它不是错了，但是有一种更好的方法可以做到这一点，这种方法对于 API 的更改更加健壮。

2.如果我不改变任何方法并运行我的应用程序与警告，我有，它会创建任何性能问题。

很可能没有。它将一如既往地发挥作用。API 方法的契约不会改变。如果一些内部数据结构发生了变化，有利于使用一种新的、更好的方法，那么可能会对性能产生影响，但这种可能性很小。

JavaAPI 中的 最有趣的讽刺是 imo，即 FontMetrics.getMaxDecent。弃用原因: 拼写错误。

不推荐。从 JDK 版本1.1.1开始，由 getMaxDescent ()取代。

小开

这并没有错，但是在软件的未来版本中会删除一些不推荐的方法，因此您可能最终会得到不能工作的代码。

小开

一般来说，使用 deprecated方法并不是绝对错误的，只要你有一个好的应急计划来避免这些方法从你使用的库中消失时出现的任何问题。对于 JavaAPI 本身，这种情况从未发生过，但对于其他任何东西，这意味着它将被删除。如果您特别计划不升级(尽管从长远来看你应该这么做)软件的支持库，那么使用 deprecated方法没有问题。
没有。

小开

术语

来自太阳官方词汇表:

反对 : 指不再推荐的类、接口、构造函数、方法或字段，在将来的版本中可能不再存在。

来自“如何以及何时反对”指南:

你可能听说过这个术语，“自我贬低的幽默,”或幽默，最小化的发言者的重要性。不推荐的类或方法就是这样的。已经不重要了。它是如此的不重要，事实上，你不应该再使用它，因为它已经被取代，并可能在未来不复存在。

@Deprecated的注释更进一步，发出了危险警告:

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

参考文献

对还是错？

使用不被推崇的方法是对还是错的问题必须在个别的基础上进行审查。下面是全部的引号，“不推荐”出现在 有效的 Java 第二版中:

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

项目66: 同步对共享可变数据的访问 : 库提供了 Thread.stop方法，但是这个方法很久以前就被废弃了，因为它本身就是 不安全——它的使用可能导致数据损坏。

第70项: 文档线程安全 : System.runFinalizersOnExit方法是线程敌对的，已被弃用。

项目73: 避免线程组 : 它们允许您同时将某些 Thread原语应用于一堆线程。这些原语中有几个已不再使用，其余的则很少使用。[ ... ]线程组已经过时了。

因此，至少对于上述所有方法，使用它们显然是错误的，至少 Josh Bloch 是这么认为的。

使用其他方法，你必须单独考虑这些问题，并且理解 为什么，它们已经被废弃了，但是一般来说，当决定废弃是合理的时候，继续使用它们会倾向于错误而不是正确。

相关问题

废弃 API 和遗留 API 的区别？

小开

除了上述所有优秀的响应之外，我还发现了删除已废弃的 API 调用的另一个原因。

在研究为什么不赞成调用时，我经常发现自己在学习关于 Java/API/框架的有趣的东西。为什么一个方法被否定，通常有一个很好的理由，理解这些理由可以得到更深层次的见解。

因此，从学习/成长的角度来看，这也是一项有价值的努力

小开

在 Java 中使用弃用的方法或类是错误的吗?”

没有错，但是可以帮你省点麻烦。下面是一个非常不鼓励使用不推荐的方法的例子:

Http://java.sun.com/j2se/1.4.2/docs/guide/misc/threadprimitivedeprecation.html

为什么不支持 Thread.stop？

因为它本身就不安全。停止线程将使其解除锁定所有被锁定的监视器。 (监视器解锁为 ThreadDeath 异常向上传播如果任何一个对象之前受到这些监视器的保护处于不一致的状态，其他线程现在可以在不一致的状态。这样的物体据说是损坏的。当线程对损坏的物体进行任意操作这种行为可能会导致微妙的，难以察觉的，或者它可以发音，不像其他的未检查的异常，ThreadDeath 静默地杀死线程; 因此，用户没有任何迹象表明他的计划堕落，堕落会显现出来本身在任何时间后，实际上发生损害，甚至几小时或几天未来。

如果不更改任何方法并运行带有警告的应用程序，会产生任何性能问题吗。

在性能方面应该没有问题。标准的 API 是为了尊重一些向下兼容而设计的，这样应用程序就可以逐渐适应较新版本的 Java。

小开

在 Java 中使用弃用的方法或类是错误的吗？ 它不是“错误的”，仍然在工作，但尽可能避免它。

假设有一个与方法相关的安全漏洞，开发人员认为这是一个设计缺陷。因此，他们可能决定放弃这种方法，引入新的方法。

所以如果你仍然使用旧的方法，你就有了威胁。因此，要了解这种贬值的原因，并检查它是否会对你产生影响。

如果不改变任何方法，并运行我的应用程序与警告，我有，它会创建任何性能问题。

如果弃权是由于性能问题，那么您将遭受性能问题的困扰，否则就没有理由出现这样的问题。再次想指出的是，要知道弃权的原因。

小开

你可能听说过“自嘲式幽默”这个词。这是幽默，最小化你的重要性。不推荐的类或方法就是这样的。已经不重要了。事实上，它是如此的不重要，以至于它根本不应该再被使用，因为它很可能在未来不复存在。

尽量避免它

小开

是的，这是错误的。

不推荐的方法或类将在未来的 Java 版本中删除，不应该使用。在每种情况下，都应该有一个可用的替代方案。用那个。

有几种情况下，为了达到项目目标，必须使用不推荐的类或方法。在这种情况下，您真的别无选择，只能使用它。Java 的未来版本可能会破坏这些代码，但是如果这是一个必要条件，你就必须接受它。这可能不是你第一次为了满足项目需求而做错事情，当然也不会是最后一次。

当您升级到新版本的 Java 或其他库时，有时您正在使用的方法或类将被弃用。不支持弃用的方法，但不应产生意外的结果。但这并不意味着他们不会，所以尽快切换你的代码。

废弃过程是为了确保作者有足够的时间将他们的代码从旧的 API 更改为新的 API。好好利用这段时间。尽快更改代码。

小开

在 Java 中是@Depreated，在 C # 中是[过时]。

我更喜欢 C # 的术语。只能说明它已经过时了。如果你愿意，你仍然可以使用它，但可能有更好的方法。

如果你认为 Windows 3.1已经过时了，那么这就像是在使用 Windows 3.1而不是 Windows 7。您仍然可以使用它，但在未来的版本中可能会有更好的特性，而且未来的版本可能会得到支持——过时的版本不会得到支持。

Java 的@Depreated 也是一样——你仍然可以使用这个方法，但是要承担风险——在将来，它可能有更好的替代方案，甚至可能不被支持。

如果您使用的代码是过时的，那么通常没有问题，只要您不必升级到新的 API ——过时的代码可能不存在。我建议，如果您看到某些代码正在使用不推荐的代码，可以更新以使用更新的替代品(这通常在注释或 Javadoc 不推荐的注释中指出)。

编辑: 正如 Michael 指出的那样，如果弃用的原因是由于功能上的缺陷(或者因为功能本不应该存在) ，那么很明显，人们不应该使用弃用的代码。

小开

当然不是，因为整个 Java 已经被@Depreated: ——)你可以随意使用它们，只要 Java 还在使用。反正也看不出有什么不同除非是真的坏了。意思是，必须先读一读，然后再做决定。

进去。然而，当一个东西被宣布过时时，即使你从来没有使用过它，也要立即去阅读它——你有大约50% 的几率认为它比替换更有效率和/或更容易使用: ——))

所以总的来说，这些天保守的技术是非常有益的，但是你必须先完成你的阅读任务。

小开

我认为不推荐的方法意味着: 有一个可用的替代 = ive 方法，它在所有方面都比现有的方法更好。使用好的方法比现有的旧方法更好。对于向下兼容来说，旧的方法被认为是不可取的。