java deprecated_在Java中使用Deprecated方法或类是错误的吗？

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

我想知道一些事情

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

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

即使你被提供Corvette Stingray，你会继续驾驶你的1955 Volkswagen Beetle吗？(0：

@KMan你将欧洲汽车与美国汽车进行比较？;)

@Ponzao和4其他人：得了！(0;

@KMan当然！

错误？ 我们在这里谈论凡人还是仅仅是静脉赘肉？

@Alexander对你的评论没有投票，所以你的+1也是;)无论如何，耐心的是新代码比旧代码好1000。 1955 Volkswagen Beetle和1956 Volkswagen Beetle之间的比较会更好，新轮胎你不知道何时会破裂！

我最近从Lucene 3.6迁移到5.3.0。 某些方法和类已被弃用。 使用这些弃用的方法时，我没有取得同样的成功。

1. Is it wrong to use Deprecated methods or classes in Java?

从弃用的定义：

A program element annotated @Deprecated is one that programmers are discouraged from using, typically because it is dangerous, or because a better alternative exists.

该方法保留在API中以便在未指定的时间段内向后兼容，并且可以在将来的版本中删除。也就是说，不，这没有错，但有一种更好的方法，它可以更好地抵御API变化。

2. What if I don't change any method and run my application with warnings that I have, will it create any performance issue.

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

Java API中最有趣的弃用是imo，即FontMetrics.getMaxDecent。弃用原因：拼写错误。

Deprecated. As of JDK version 1.1.1, replaced by getMaxDescent().

Java API中下一个最有趣的弃用是AbstractButton(Swing)中的setMultiClickThreshhold(int threshhold)和getMultiClickTreshhold()。为这两个做好准备！ ;)

我们需要使用HTTP REFERER执行此操作。令人抓狂：en.wikipedia.org/wiki/HTTP_referer

@DaveMcClelland，从69：D开始70;)

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

你怎么能确定它没有改变性能？例如，去除可以是由于内部数据结构的改变，例如从HashSet到TreeSet的改变。

@aioobe - 根据我的理解，OP询问是否调用已弃用的代码是否有任何性能问题，它没有给出它不会改变生成的字节代码(在1.5之前是在javadoc中，现在注释正在使用中，但仍然没有改变到性能)

当从一个版本的库转到另一个版本时，不能保证新版本中方法的字节代码与先前版本中相同方法的字节代码相同。

@aioobe - 有一个保证简单地让它弃用不会改变字节代码，这就是我认为OP意味着的。当然代码本身会发生变化，这就是我们弃用代码的原因。

如果您继续使用与以前相同的版本，则没有任何变化。但是，如果您使用较新版本的库，并且他们没有弃用API，那么可能会改变性能，如果底层实现被彻底改变并且新API利用它，而旧API不是对于这种新的结构，过去是有效的。

术语

来自官方的Sun词汇表：

deprecation: Refers to a class, interface, constructor, method or field that is no longer recommended, and may cease to exist in a future version.

从何时何时弃用指南：

You may have heard the term,"self-deprecating humor," or humor that minimizes the speaker's importance. A deprecated class or method is like that. It is no longer important. It is so unimportant, in fact, that you should no longer use it, since it has been superseded and may cease to exist in the future.

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

A program element annotated @Deprecated is one that programmers are discouraged from using, typically because it is dangerous, or because a better alternative exists.

参考

java.sun.com词汇表

语言指南/如何以及何时弃用API

注释类型不推荐使用的API

对还是错？

使用弃用方法是对还是错的问题必须逐个审查。以下是有效Java第2版中出现"deprecated"一词的所有引号：

Item 7: Avoid finalizers: The only methods that claim to guarantee finalization are System.runFinalizersOnExit and its evil twin Runtime.runFinalizersOnExit. These methods are fatally flawed and have been deprecated.

Item 66: Synchronize access to shared mutable data: The libraries provide the Thread.stop method, but this method was deprecated long ago because it's inherently unsafe -- its use can result in data corruption.

Item 70: Document thread safety: The System.runFinalizersOnExit method is thread-hostile and has been deprecated.

Item 73: Avoid thread groups: They allow you to apply certain Thread primitives to a bunch of threads at once. Several of these primitives have been deprecated, and the remainder are infrequently used. [...] thread groups are obsolete.

所以至少在上述所有方法中，使用它们显然是错误的，至少根据Josh Bloch的说法。

使用其他方法，您必须单独考虑这些问题，并了解它们被弃用的原因，但一般来说，当弃用的决定合理时，它倾向于倾向于错误而不是继续使用它们。

相关问题

Deprecated和Legacy API之间的区别？

"弃用"来自拉丁语"de"+"precare"，意思是"祈祷反对"。当某些东西被描述为弃用时，标准正在祈祷 - 乞求 - 你不要使用它;它是一个警告，可能会在该标准的未来版本中删除它。请注意，在该标准的当前版本的任何实现中都需要完全实现已弃用的功能。不过，你提到的自嘲幽默有点不合时宜;在这种意义上，"自我贬低"是一种"自我贬低"的腐败，它具有不同的衍生和含义。

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

正在研究为什么不推荐使用调用我经常发现自己正在学习有关Java / API / Framework的有趣内容。通常有一个很好的理由可以推断某种方法，并了解这些原因可以获得更深入的见解。

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

它当然不会产生性能问题 - 将来不推荐使用的功能可能是函数不再是库的一部分，因此您应该避免在新代码中使用它并更改旧代码以停止使用它，所以有一天升级struts并发现该函数不再存在时，你不会遇到问题

从经验来看，"弃用"的确意味着"你不应再使用它了，但它将永远可用。"至少对于Java Standard API，我不知道在弃用之后是否实际删除了任何方法或类。

@Michael嗯，在实践中，API很少删除已弃用的函数，因为编译器输出"警告：停止使用你这个傻瓜"可能会被弃用十年，人们仍然可以在他们最终删除它的那一天翻出来。我认为弃用应该意味着"有一天我们想要把它拿掉，所以请停止使用它"，即使在实践中很少实际发生

@Michael Mrozek：不同意声明It certainly doesnt create a performance issue;它过于主观，无法说明。

@KMan被标记为已弃用的函数不会以某种方式使其效率低于被标记之前的函数 - 它将与以前完全相同

@Michael Borgwardt：这就是它在大多数标准化语言中的运作方式。当然，如果要从标准中删除任何弃用的东西，流行的实现会将其作为扩展。

@David你回复我，而不是Borgwardt。不幸的是，我不确定是否有办法回复他(见子弹4和5)

现在这是一个想法...如果他们让被弃用的方法执行缓慢，并逐渐越来越多，所以每个版本，然后最终人们将停止使用它。在某些时候，剩下的用途太少，可以从API中删除。

实际上是否从标准Ja??va API中删除了已弃用的方法？任何例子？

你可能听说过"自嘲幽默"这个词。这是幽默，可以最大限度地减少你的重要性。不推荐使用的类或方法就是这样。它不再重要。事实上，它根本不应该被使用，因为它可能在将来不再存在。

尽量避免它

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

通常不会，使用deprecated方法并不是绝对错误的，只要你有一个很好的应急计划，以避免任何问题，如果/当这些方法从你正在使用的库中消失时。使用Java API本身就不会发生这种情况，但几乎任何事情都意味着它将被删除。如果您特别计划不升级(尽管您很可能从长远来看)您的软件支持库，那么使用deprecated方法就没有问题。

没有。

是的，这是错的。

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

在某些情况下，您必须使用已弃用的类或方法才能实现项目目标。在这种情况下，你真的别无选择，只能使用它。 Java的未来版本可能会破坏该代码，但如果这是一个要求，您必须接受它。这可能不是你第一次为了满足项目要求而做错事，而且肯定不会是最后一次。

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

弃用过程用于确保作者有足够的时间将其代码从旧API更改为新API。利用这个时间。尽快更改代码。

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

这不是"错误的"，仍在工作，但尽可能避免它。

假设存在与方法相关的安全漏洞，开发人员确定这是一个设计缺陷。因此他们可能决定弃用该方法并引入新方法。

因此，如果您仍然使用旧方法，则会产生威胁。因此，请注意弃用的原因并检查它是否会对您产生影响。

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

如果弃用是由性能问题引起的，那么您将遇到性能问题，否则没有理由遇到此类问题。再次想指出，请注意弃用的原因。

Is it wrong to use Deprecated methods or classes in Java?"

这样没错，但它可以省去一些麻烦。这是一个强烈建议不要使用弃用方法的示例：

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

Why is Thread.stop deprecated?

Because it is inherently unsafe.

Stopping a thread causes it to unlock

all the monitors that it has locked.

(The monitors are unlocked as the

ThreadDeath exception propagates up

the stack.) If any of the objects

previously protected by these monitors

were in an inconsistent state, other

threads may now view these objects in

an inconsistent state. Such objects

are said to be damaged. When threads

operate on damaged objects, arbitrary

behavior can result. This behavior may

be subtle and difficult to detect, or

it may be pronounced. Unlike other

unchecked exceptions, ThreadDeath

kills threads silently; thus, the user

has no warning that his program may be

corrupted. The corruption can manifest

itself at any time after the actual

damage occurs, even hours or days in

the future.

What if don't change any method and run my application with warnings that I have, will it create any performance issue.

在性能方面应该没有问题。标准API旨在尊重一些向后兼容性，因此应用程序可以逐步适应新版本的Java。

这没有错，但是在软件的未来版本中删除了一些已弃用的方法，因此最终可能会导致代码无效。

Removed？请参阅定义stackoverflow.com/questions/2941900/

@KMan - 在您发布的链接中写道 -"该方法保留在API中以便在未指定的时间段内向后兼容，并且可能在将来的版本中被删除。"我已经写了相同的内容 - 一些被弃用的方法可能会在近期或远期被删除。

我觉得弃用的方法意味着; 有一个备用= ive方法可用，它在各个方面都比现有方法更好。 最好使用比现有旧方法更好的方法。 为了向后兼容，旧方法保留为已弃用。

当然不是 - 因为整个Java都得到了@Deprecated :-)，只要Java持续，你就可以随意使用它们。 不管怎么说都不会注意到任何差异，除非它真的被打破了。 意义 - 必须阅读它然后决定。

然而，在.Net中，当某些内容被声明[已过时]时，即使您以前从未使用它，也要立即阅读它 - 您有大约50％的可能性比使用它更有效和/或更容易使用:-))

所以总的来说，现在技术保守是非常有益的，但你必须先做你的阅读家务。

在Java中它是@Deprecated，在C＃中它是[已废弃]。

我想我更喜欢C＃的术语。这只是意味着它已经过时了。如果你愿意，你仍然可以使用它，但可能有更好的方法。

如果你认为Windows 3.1已经过时，就像使用Windows 3.1而不是Windows 7。你仍然可以使用它，但未来的版本可能有更好的功能，而且可能会支持未来的版本 - 过时的版本不会。

对于Java的@Deprecated也是如此 - 您仍然可以使用该方法，但风险自负 - 将来可能有更好的替代方案，甚至可能不受支持。

如果您使用的是不推荐使用的代码，那么它通常很好，只要您不必升级到更新的API - 那里可能不存在已弃用的代码。我建议如果你看到使用弃用代码的东西，要更新以使用更新的替代品(这通常在注释或Javadoc弃用的注释中指出)。

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

"如果您使用的是已弃用的代码，那么它很好，只要您不必升级到更新的API" - 就不行了。看看为什么不推荐使用Thread.stop()，你会发现它在任何JRE版本中都没有问题。

好吧，我宁愿说"通常"很好(会更新那一点):)因此，使用风险自负。显然，如果弃用它的原因是为了阻止其功能的缺陷，那么不使用它是有意义的。一般来说，使用不推荐的方法很好。所以ja，这一切都取决于弃用的原因。真正。