已弃用API和旧版API之间的区别？ [英] Difference between a deprecated and a legacy API?
问题描述
我在Java的 Collection Framework 中学习了遗留的API，我了解到 Vector code> HashTable 已被 ArrayList 和 HashMap 取代。
然而，它们仍然不被弃用，并且被认为是遗留的，本质上，deprecation应用于被取代的软件功能，应该避免，所以，我不知道什么时候是API
从官方Sun词汇表：
弃用：指不再推荐的类，接口，构造函数，方法或字段，并且可能在未来版本中不再存在。
从弃用指南的使用方法：
你可能听说过这个词，自我贬低的幽默或幽默，这最大限度地降低了说话者的重要性。一个弃用的类或方法就是这样。它不再重要。事实上，这是不重要的，因为它已被取代，并且可能会在将来停止存在。
@Deprecated 注释更进一步，警告危险：
注释
@Deprecated的程序元素是程序员不愿使用的程序元素，通常是因为它是危险的，或者因为存在更好的替代。 / p>
参考资料
请注意，官方词汇表并没有定义legacy手段。很可能，这可能是Josh Bloch使用的一个术语，没有一个确切的定义。
也许一个旧的代码使用遗留但非过时的类
相反，弃用显式警告他们可能会停止
来自有效Java第2版的引用
为了比较这些术语在上下文中是如何使用的，这些是来自书的引用，其中出现了已过时的字：
项目7：避免finalizer ：声明保证最终化的唯一方法是
System.runFinalizersOnExit及其邪恶的双胞胎Runtime.runFinalizersOnExit。
项目66：同步共享可变数据的访问：库提供
Thread.stop方法，但此方法很久以前已弃用，因为它本来就是不安全 - 其使用会导致数据损坏。
项目70：文档线程安全：
System.runFinalizersOnExit方法是线程敌意的， p>
项目73：避免线程组：它们允许您将某些
线程束线程一次。其中一些原语已被弃用，其余的很少使用。 [...]个线程组已过时。
/ em>出现：
项目23：不要在新代码中使用原始类型：
项目25：首选数组列表：Erasure是什么允许泛型类型可以自由地与不使用泛型的旧代码进行互操作。
项目29：考虑类型安全的异构容器：这些封装器可用于跟踪谁
项目54：明智地使用原生方法：它们提供了访问遗留代码库，从而提供对遗留数据的访问。 [...]使用本地方法访问旧代码也是合法的。 [...]如果必须使用本地方法访问低级资源或旧版本库，请尽可能少使用本地代码，并进行彻底测试。
项目69：希望并发实用程序等待和通知：虽然应始终优先使用并发实用程序，优先于
wait和/ code>，您可能必须维护使用wait和通知的旧代码。
这些引号未经过精心挑选：它们是所有包含已弃用字词和 出现在书中。 Bloch的信息很清楚：
- 已弃用的方法，例如
Thread.stop是危险的，应该永远不会使用 。 - ，例如
wait / notify可以保留在旧代码中，但不应在新代码中使用。
我自己的主观意见
我的解释是，弃用的东西承认这是一个错误，从来没有好开始。另一方面，分类某事是一种遗产，承认它在过去是足够好，但它已经达到了它的目的，对于现在和未来来说已经不够好了。
I was studying the legacy API's in the Java's Collection Framework and I learnt that classes such as Vector and HashTable have been superseded by ArrayList and HashMap.
However still they are NOT deprecated, and deemed as legacy when essentially, deprecation is applied to software features that are superseded and should be avoided, so, I am not sure when is a API deemed legacy and when it is deprecated.
From the official Sun glossary:
deprecation: Refers to a class, interface, constructor, method or field that is no longer recommended, and may cease to exist in a future version.
From the how-and-when to deprecate guide:
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.
The @Deprecated annotation went a step further and warn of danger:
A program element annotated
@Deprecatedis one that programmers are discouraged from using, typically because it is dangerous, or because a better alternative exists.
References
Note that the official glossary does not define what "legacy" means. In all likelihood, it may be a term that Josh Bloch used without an exact definition. The implication, though, is always that a legacy class should never be used in new code, and better replacement exists.
Perhaps an old code using legacy but non-deprecated class requires no action, since for now at least, they aren't in danger of ceasing to exist in future version.
In contrast, deprecation explicitly warns that they may cease to exist, so action should be taken to migrate to the replacement.
Quotes from Effective Java 2nd Edition
For comparison on how these terms are used in context, these are quotes from the book where the word "deprecated" appears:
Item 7: Avoid finalizers: The only methods that claim to guarantee finalization are
System.runFinalizersOnExitand its evil twinRuntime.runFinalizersOnExit. These methods are fatally flawed and have been deprecated.Item 66: Synchronize access to shared mutable data: The libraries provide the
Thread.stopmethod, 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.runFinalizersOnExitmethod is thread-hostile and has been deprecated.Item 73: Avoid thread groups: They allow you to apply certain
Threadprimitives to a bunch of threads at once. Several of these primitives have been deprecated, and the remainder are infrequently used. [...] thread groups are obsolete.
By contrast, these are the quotes where the word "legacy" appears:
Item 23: Don't use raw types in new code: They are provided for compatibility and interoperability with legacy code that predates the introduction of generics.
Item 25: Prefer lists to arrays: Erasure is what allows generic types to interoperate freely with legacy code that does not use generics.
Item 29: Consider typesafe heterogeneous containers: These wrappers are useful for tracking down who adds an incorrectly typed element to a collection in an application that mixes generic and legacy code.
Item 54: Use native methods judiciously: They provide access to libraries of legacy code, which could in turn provide access to legacy data. [...] It is also legitimate to use native methods to access legacy code. [...] If you must use native methods to access low-level resources or legacy libraries, use as little native code as possible and test it thoroughly.
Item 69: Prefer concurrency utilities to wait and notify: While you should always use the concurrency utilities in preference to
waitandnotify, you might have to maintain legacy code that useswaitandnotify.
These quotes were not carefully selected: they're ALL instances where the word "deprecated" and "legacy" appear in the book. Bloch's message is clear here:
- Deprecated methods, e.g.
Thread.stop, are dangerous, and should never be used at all. - On the other hand, e.g.
wait/notifycan stay in legacy code, but should not be used in new code.
My own subjective opinion
My interpretation is that deprecating something is admitting that it is a mistake, and was never good to begin with. On the other hand, classifying that something is a legacy is admitting that it was good enough in the past, but it has served its purpose and is no longer good enough for the present and the future.
这篇关于已弃用API和旧版API之间的区别？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
