java - 仅更改源版本和目标版本后要测试的内容

Question

我们一直在关注官方Java migration guide将我们的应用程序从 Java 6 升级到 Java 8。不幸的是，我们没有将源和目标版本设置为 1.8 以防止使用新的语言功能。

因此，目前我们正在使用 JDK 1.8/JRE 1.8 编译和执行我们的应用程序，但将源和目标级别设置为 1.6。

尽管如此，我们现在甚至想将应用程序的源和目标级别升级到 1.8。

设置这些属性只会改变编译允许的功能和类的二进制格式，还是配置会改变应用程序的语义？我们希望在将源版本和目标版本更新到更高版本时，在保持相同的 JRE 执行和 JDK 编译时，不应该有任何已知问题或不兼容。

Answer 1

Does setting those properties only changes the allowed features for the compilation and the binary format of the classes or does the configuration changes the semantics of the application?

它实际上可以改变Java语言的语义。例如，@Overrides 的含义在 Java 5 和 Java 6 之间发生了变化。(我不记得在 Java 6 和 Java 8 之间有任何类似的变化，但是......)

当然还有:

• 将修复库错误。
• 在某些情况下，会重新实现方法或类(例如 Arrays.sort 和 HashMap)，但在库行为的未指定方面存在差异。
• 对 JIT 编译器的更改可能会导致 native 代码以不同方式进行优化，这可能会导致(您的)有问题的多线程代码出现时序或内存模型相关的回归。

简而言之，即使从一个版本升级到下一个版本......或者只是更改 --source 或 --target 通常是无害的，但有时它可以导致需要解决的问题。

所以...测试一切...彻底。不要假设当您推出我们的新版本时它就可以正常工作。

当然，建议阅读相应发行说明中的​​错误修复和不兼容性列表。但请注意，列表可能不完整，或者您不会意识到某些修复会影响您的代码。 (谁知道/记得多年前编写的大型应用程序的每个实现细节？)请注意，新主要版本中的已修复错误列表是从以前的补丁版本中增加的。

---

相反的是，你不能只是推迟升级，因为。你推迟的时间越长，它变得越难，你的代码库的技术债务就越大。而且您可能会发现自己不得不 panic 地进行升级；例如由于未修补的安全问题、操作系统支持问题等。