Ben*_* Xu 7 java backwards-compatibility
详细说明:如果我们使用公共API,例如,在JDK 1.4中编写java程序,如果应该在其上面的所有版本中正确运行.1.4中的所有更新版本,1.5,1.6和1.7？
另外,不同更新程序版本之间的可梳理性规则是什么,例如1.6.22和1.6.23哪些不能更改,哪些可以更改？当然,公共API定义无法改变,其他人怎么样？javadoc的？内部API定义,实现？
如果有人可以就这一主题指出具体的官方文件,那将是很棒的.谢谢,
java文档中有一个例子,它们不打算在更新程序版本之间进行更改.请参阅http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6475885
这应该是它的大局之一,但我们最好对此有一个完整的描述.
需要知道完整的故事,以便我们感到安全升级到更大的版本.
一般规则是,任何针对Java API编写和编译的代码X 都应该在Java Y上运行Y >= X.
偶尔有例外; 例如,应用程序的行为取决于Java X中的某些未记录的行为(通常是错误),这些行为在更高版本中得到了纠正.
AFAIK,没有列出这些不兼容性的单一文档.所有Java主要版本的发行说明都包含可能导致旧代码损坏的更改列表.
话虽如此,谨慎的方法是确保在升级到更新的Java版本时彻底测试/重新测试软件.如果你的软件交付给客户/客户,让他们知道,如果/当它是安全的,他们升级,并(在必要时),为他们提供修复程序,该你的测试已发现的任何问题.
需要知道完整的故事,以便我们感到安全升级到更大的版本.
感觉安全是不重要的.在更高版本上彻底测试您的应用程序.这是唯一切实可行的解决方案.即使每个不兼容性都被详尽记录,情况也是如此.
想一想.您如何确定您的应用程序不会以某种方式受到XYZ变更的影响？或者您使用的某些第三方库不会受到影响？答:你不能.
这里没有任何抱怨你认为Oracle应该以不同方式处理这个问题的方式会产生任何不同.并非我认为他们可以在不改变商业模式的情况下更好地处理这个问题.您是否准备为保证没有版本兼容性问题的Java平台支付多少费用？
这不是完整的答案，但我要补充一点，will-it-run 和 will-it-compile 是两个不同的东西。1.5 中引入的关键字将阻止某些 1.4 代码编译，但字节代码可以正常运行。