JDK，JRE兼容JAR
我对JDK和JRE源代码和二进制兼容性（例如this和this ）有所了解，但不确定以下情况：
考虑我有一个使用JDK5编译并在JRE6上运行的应用程序。 它使用一些库（jar），它们也使用JDK5编译。
现在我想使用JDK6编译我的应用程序。 在这种情况下运行时会出现什么新问题（特别是与“旧”jar子的兼容性）？ 我应该完全重新测试应用程序（触摸每个库）还是可以依赖于承诺的JDK / JRE兼容性？
通常，如果将JDK6的编译器选项设置为使用1.5源兼容性，则不会出现任何问题 。 然而， 有时这并非总是如此 。
我记得曾经用1.5编译器编译1.4代码（使用1.4兼容性）。 好的jar子里面（1.4二进制级别），但由于有趣的转换，应用程序崩溃了。
我们使用BigDecimal数字将一个整数作为参数传递给构造函数。 1.4版本只有一个来自double的构造函数，但1.5版本同时具有int和double构造函数。 因此，当使用1.4编译器进行编译时，会自动从int转换为double ，但是使用1.5编译器检查int构造函数是否存在并且没有实现转换。 然后，当在1.4 JRE上使用完美的二进制兼容代码时，程序会因NoSuchMethodException崩溃。
我不得不承认这是一个奇怪的案例，但这是逻辑不起作用的案例之一。 所以我的建议是，如果您计划编译旧版本的JRE，请尽可能使用目标版本JDK。
除非您没有更改代码并添加新的Java 6function，否则应该没有问题。 关于其他jar子，应该没有任何问题。 JDK始终保持向后兼容性。
兼容性大多有效。 除了不使用generics的各种警告之外，我不希望出现任何问题。 也许一些几乎没有使用过的API已被弃用，但我认为它们已经保留到位，只是标记为已弃用。
试试吧，如果它编译你应该没问题 。
Java的一个关键设计方面 – 遗憾的是 – 完全向后兼容。
很少有例外，其中不保留向后兼容性; 当排序算法从稳定排序算法变为非稳定排序算法时，Eclipse最突出的是（不再保留相同排序的对象的顺序）; 但这绝不是Java规范的一部分，而是Eclipse中的一个错误。
这是不幸的，因为有一些糟糕的选择现在无法改变。 Iterator不应该在API中有一个remove()函数， Vector不应该已经同步（现在通过使用ArrayList解决）， StringBuffer不应该已经同步，因此StringBuilder 。 String应该是一个接口，而不是一个类，允许例如8位字符串，32位字符串 – CharSequence是更好的字符串接口，但是太多方法不接受CharSequence并且需要返回一个String 。 Observable应该是一个接口：你不能使用这个API使子类可观察。 仅举几例。 但由于向后兼容性，这些不能再修复，直到JDK模块化（此时有些可能至少消失在donotuse模块中……）。
当然你应该已经有成千上万的unit testing来帮助你测试新的JDK …… 🙂