我正在研究Java Collection Framework中的遗留API，我了解到Vector和HashTable等类已被ArrayList和HashMap取代
然而，它们仍然不被弃用，并且在本质上被视为遗留，弃用适用于被取代且应该避免的软件功能，因此，我不确定什么时候API被认为是遗留的以及何时被弃用。< / p>
答案 0 :(得分：27)
来自官方的Sun词汇表：
弃用：指不再推荐的类，接口，构造函数，方法或字段，并且可能在将来的版本中不再存在。
从何时何时弃用指南：
你可能已经听过“自我贬低的幽默”这个词，或者说幽默，可以最大限度地减少说话者的重要性。不推荐使用的类或方法就是这样。它不再重要。事实上，你不应该再使用它，因为它已被取代并且将来可能不再存在，这是非常不重要的。
@Deprecated注释更进一步，警告危险：
注释
@Deprecated的程序元素是程序员不鼓励使用的程序元素，通常是因为它危险，或者因为存在更好的替代方案。
请注意，官方词汇表没有定义“遗产”的含义。很可能，这可能是Josh Bloch在没有确切定义的情况下使用的术语。但是，这意味着永远不应该在新代码中使用遗留类，并且存在更好的替换。
使用遗留但未弃用的类的旧代码可能不需要操作，因为至少现在它们不会在将来的版本中不再存在。
相反，弃用明确警告它们可能不再存在，因此应采取措施迁移到替代品。
为了比较这些术语在上下文中的使用方式，这些是本书中引用“不赞成”一词的引用：
第7项：避免使用终结者：声称保证最终确定的唯一方法是
System.runFinalizersOnExit及其邪恶双胞胎Runtime.runFinalizersOnExit。这些方法存在致命缺陷，已被弃用。项目66：同步对共享可变数据的访问：这些库提供了
Thread.stop方法，但这种方法很久以前就已弃用，因为它本身就是不安全 - - 它的使用可能导致数据损坏。项目70：记录线程安全性：
System.runFinalizersOnExit方法是线程不可用的，已被弃用。第73项：避免线程组：它们允许您同时将某些
Thread原语应用于一堆线程。其中一些原语已被弃用，其余原语很少使用。 [...]线程组已经过时。
相比之下，这些是“legacy”这个词的引号：
第23项：不要在新代码中使用原始类型：它们与遗留代码的兼容性和互操作性提供，这些代码早于引入泛型。
第25项：首选列表到数组：Erasure允许泛型类型与不使用泛型的遗留代码自由互操作。
第29项：考虑使用类型安全的异构容器：这些包装器可用于跟踪将错误键入的元素添加到混合泛型和遗留代码的应用程序中的集合的人。
项目54：明智地使用本机方法：它们提供对遗留代码库的访问，这些代码可以反过来提供对遗留数据的访问。 [...]使用本机方法访问遗留代码也是合法的。 [...]如果必须使用本机方法访问低级资源或旧库，请尽可能少使用本机代码并对其进行全面测试。
项目69：首选并发实用程序等待并通知：虽然您应该始终使用并发实用程序优先于
wait和notify，但您可能必须维护旧版本使用wait和notify的代码。
这些引用未经过仔细选择：它们是书中出现“不赞成”和“遗产”这一词的所有实例。布洛赫的信息很清楚：
Thread.stop是危险的，永远不会wait/notify可以保留在遗留代码中，但不应在新代码中使用。我的解释是，弃用某些东西是承认这是一个错误，并且开始时从来都不是好事。另一方面，将某事物归类为遗产就是承认它在过去已经足够好了，但它已经达到了目的，对现在和将来来说已经不够好了。
答案 1 :(得分：14)
一个常见的解释是，Deprecated意味着它将在不久的将来被删除，而Legacy意味着它将保留以用于向后兼容或其他原因。
两者都意味着新代码不应该使用它们。
对于JDK，即使是不推荐使用的代码仍然存在，因为向后兼容性对Java JDK非常重要。
答案 2 :(得分：0)
弃用通常表示有意在将来的某个时刻删除功能，而遗留只是暗示它不应该在新代码中使用（尽管可能因为互操作原因需要）
答案 3 :(得分：0)
Deprecated注释提供了已弃用API的正式定义。我认为遗留类的正式定义不存在。两者实际上都意味着不应该在新代码中使用该类。
答案 4 :(得分：0)
我有一个建议 - 遗产是指过去编写的代码，弃用是指不再使用它的建议。您仍然可以使用弃用的api，但是您不能编写遗留代码，因为您现在正在编写它。 只是恕我直言
答案 5 :(得分：0)
弃用意味着它很糟糕且不应该使用 - File.toURL()是一个主要的例子，因为它不会从路径中带空格的文件创建正确的URL。它根本就没有做它应该做的事情，但是因为现有代码可能正在使用如果错误得到修复就会破坏的解决方法
遗产只是意味着它已经过时了，并且有办法做一些但不一定更好的事情。 Vector是一个很好的例子 - 它是一个List实现，但是在收集API（即List）设计之前的几天仍然有一些丑陋的废话。它也是同步的，这意味着即使在单线程场景中使用它也必须支付同步费（除了在某些情况下VM很聪明）。 ArrayList如果你想要一个支持数组的列表实现更好，因为它是不同步的，并且Collections.synchronizedList在你想要一个同步列表时更灵活，因为它是一个可以用于所有列表实现的包装器（链表，来自Arrays.asList(T...)的列表等）。但是，如果你做碰巧想要一个同步的，数组支持的列表实现，那么Vector就可以了。
答案 6 :(得分：0)
我的解释是，传统代码只是有更新的对应物，可以更好地完成工作。但是，它将继续收到错误修复和其他支持。另一方面，不推荐使用的代码不受支持，也不会收到专门的错误修复。