答案 0 :(得分：11)
正如我already mentioned，即使在其How and When To Deprecate APIs中，关于实际删除已弃用的API的政策也没有任何说明......
基于旧JVM（例如1.4）的应用程序数量仍然很重要，部分原因是应用程序服务器需要很长时间才能使用新版本的JVM验证自己... < / p>
实际在生产中运行的应用程序数量绝对意味着这种“向后兼容”政策可能不会很快被破坏。
答案 1 :(得分：7)
有几种向后兼容性：
旧源代码可以用新编译器编译吗？
这可以通过将旧构造转换为新构造的工具来处理，或者使用类似“源1.6”的东西来处理。指令位于文件顶部。
旧的类文件可以在新的JVM中运行吗？
在我的世界里，这是一个完整的表演终结者。我们使用如此多的第三方库来强制同时升级所有这些库会成本太高。
这也是不删除弃用类和方法的驱动因素，但程度较小。
旧类文件可以调用用新编译器编译的代码吗？
由于回调，这是＃2的重要部分。
新编译的代码可以调用旧类文件中的代码吗？
＃2的另一个重要部分。
代码看起来与开发人员大致相似吗？
这对于培训和处理尚未完全转换的大型代码库非常重要。更微妙的方面是在混合代码库中可以使用多少新功能。如果你打破这个太远，你就会得到类似Scala而不是Java ++的东西。
添加泛型以保留所有这些类型的兼容性。我认为对Java的任何不兼容的更改都必须保留至少2,3和4才有可能被接受为 Java 。处理＃1的工具也是最低要求。
答案 2 :(得分：4)
您可以使用业余爱好（Ruby），低实现（Python）语言来完成此任务，但您无法想象全世界有多少应用程序是用Java编写的。只需检查freshmeat或sourceforge。这只是一部分。所以不，这不是一个好主意。实际上，这是一个非常愚蠢的想法。
没有两个GUI框架。 Swing取决于并使用AWT作为基础。
答案 3 :(得分：3)
如果删除某些已弃用的功能，我会非常乐意 - 例如，如果Date对象真正变为不可变，我会非常高兴。实际上，如果你正在编写一个不可变类，你不能假设Dates是不可变的，并且必须防御性地复制它们，例如，你不能可靠地将它们用作Hashmaps中的键（因为在这两种情况下，其他代码无论方法是否注释为已弃用，都可以改变日期。
在添加新的语言功能时，我并不完全理解向后兼容性的口头禅。在我看来，如果为以前的版本编写的代码需要在以后的版本中运行一些调整，那就没什么大不了的。事实上，无论如何都有先例;在1.5和1.6之间，在ResultSet接口中添加了额外的方法，因此在Java 1.5下编译和运行的代码甚至不能在1.6下编译。
考虑到遗留应用程序，有人期望未在5年内更新的应用程序能够在最新版本的JVM上完美运行，这是否合理？如果组织仍在使用Java 1.4和为其编写的应用程序，那么他们真的关心Java 7中的内容吗？向后兼容性并不意味着所有以前版本的JVM也会被破坏。如果应用程序的目标是早期版本，那么可以在该版本的JVM上运行它，无需担心。
最重要的是，随着时间的推移，人们使用Java，错误和功能差距变得明显，纠正/实施这些将是一个重大的福音。如果不幸的话，在尝试改善语言的时候会因为前面的事情而被束缚，而且在我看来并不是一个基本的要求。
当然，需要对升级路径有所考虑。例如，要突然将int更改为Integers，需要为每个人进行大量繁琐的代码更改（以及必须添加额外的空值检查等）。但是，添加一个碰巧向后兼容性（例如，关闭）的新功能，或者删除已弃用多年的方法，对现有代码几乎没有影响。 （如果你一直在使用弃用的方法然后很难，你应该先删除它们，但现在你被迫了！）
答案 4 :(得分：3)
出于兼容性原因，他们无法使用标准Java版本。现在有很多Java软件正在生产中，你根本无法通过一个新的版本来解决它，从而消除了所有这些问题。
但是，我确实认为Sun可以制作一个“Java X”版本，删除了所有苛刻的内容，并添加了所有优秀且有用的API，但目前尚未包含（包括替换具有更好替代品的Java API）例如，log4j，让我们不要在日期和日历上开始）。此版本不会用于替换Java，但可以作为新软件项目的目标存在。我猜他们也可以修复语言，包括缺少的功能，使Java看起来与最新版本的C＃相比有点苛刻，等等。如果他们制作了一个代码移植工具，可以修复或至少添加“FIXME”到代码库中的所有问题区域......
必须承认，微软在推出新版本的.NET时做得很好。鉴于仍在1.4上运行的应用程序的数量，以及许多公司的昏昏欲睡的Java版本政策（他们似乎很乐意让他们的.NET用户使用最新和最好的某种方式），Sun在这里完全失败了。鉴于在一台机器上安装多个Java很简单，我认为应该做更多工作来鼓励公司和软件公司更快地升级。
答案 5 :(得分：2)
我会说破解向后兼容性对于java来说是一件愚蠢的事情。如果是这样，你可以称之为Java ++，它不再是Java。另一方面，对于Java的未来版本，它应该从动态语言中学习语法简单性等功能。由于硬件功率正在快速增长，因此编译语言的抽象级别应该更高。将当前Java版本的某些功能与动态语言进行比较，它太笨拙和冗长，因此开发效率较低。看来C＃正在成为一种动态语言？
答案 6 :(得分：2)
在JVM上有许多很棒的替代语言，我真的没有看到任何理由。我宁愿有一个稳定的Java，继续寻找很酷的新东西（并且仍然与Java兼容）。
答案 7 :(得分：1)
因为，大部分市场份额仍然使用较旧的jdk / jre，我认为打破向后兼容性不会是务实的。
答案 8 :(得分：0)
正如Pat所说，采用最新的JDK版本的速度非常慢，目前很多应用程序都使用旧版本（有时是旧版本）运行。
因此，我认为不能确保向后兼容性会带来真正的好处。
对于你的建议，我真的没有看到删除原语的兴趣。当然，自Java 5以来就有自动装箱。然而原始人仍然有他们的兴趣......
答案 9 :(得分：0)
如果JVM保持不变，那么破坏兼容性是有意义的。在这种情况下，“新”Java将成为在JVM上运行的新的不同语言，例如列出的there。幸运的是，JVM的设计方式保证了语言和版本之间的互操作性，因此我认为其影响是有限的。
答案 10 :(得分：0)
我认为分叉更适合给语言进行适当的改革。坦率地说，Java的泛型工作方式开始让我感到沮丧。
答案 11 :(得分：0)
我离开PHP的原因是它们改变了主要版本升级之间的API /可用功能。真正的问题是，对于较旧的脚本，PHP无法在兼容模式下运行。我不想被迫升级我的代码。
Java在同一个地方。只需确保您可以在新版本上使用旧的1.4内容。可以要求新程序使用新的xyntax，但要让旧的东西运行！
答案 12 :(得分：0)
关于基元，它们将永远存在，不管它是否相同，因为它们是对象的基本构建块。当然，您可以使用包装类，但这只会过度使用编译器，在大多数情况下最终会转换回原语。
向后兼容性非常重要，正如这里已经提到的那样，有很多用户仍在运行1.3和1.4代码。话虽如此，我认为如果有人仍然在某些遗留系统中运行java 1.0或1.1代码，他们不太可能很快迁移到Java 7，即使他们这样做，他们也很可能需要重写他们的代码无论如何。我认为可以安全地删除版本＆gt; 1.2的已弃用的API。
向后兼容性的另一个方面是添加关键字，但总是不鼓励这样做。在Java 5中，主要的语言更改是通过添加一个新的关键字'enum'来管理的，甚至引起了愤怒，因为每个带有名为'enum'的变量的代码现在都不合规。据我所知，Java 7中的更改是在没有新关键字的情况下计划的（p！）。
Yuval = 8 - ）
答案 13 :(得分：0)
这将是好的，取决于Sun不会向所有客户推出新的JDK升级。那些使用旧API的人不会升级，并且会暂时使用旧版本的JDK。
或者，也许是通过实现向后兼容模式。
答案 14 :(得分：0)