在成功升级到Java 9后，我们试图进一步升级到Java 10。然而，遇到了IntelliJ IDEA的一个bug，该IDE错误地理解了一个尚未生效的草案JEP182，导致编译器给出了不正确的结果，我们花费了大量时间才找到问题的根源。这表明即使在大型公司中，兼容性问题也可能在升级过程中出现。业界的许多工具不支持Java 9，F...
java14都快出来了，为什么还有那么多人执着于java8？
Java 9的发布在2017年9月，而到了2018年9月，我们的公司花了整整一年的时间才切换到Java 9，接着又花了三个月的时间升级到Java 11。对比之下，JetBrains似乎用了两年多的时间才将运行时升级到11版本，尽管两者代码规模相当，都是百万级别的。因此，我们可以得出，Java 9的许多奇特改动以及业界累积的库中不规范的使用方式导致了大部分项目被迫停留在Java 8上。
在迁移Java 9/11的过程中，我们遇到了许多问题。Java 9之前的版本号使用标准格式，例如1.8.0_213。然而，Java 9引入了JEP223，一个所谓的语义化版本号，例如9.0.0.4。这种变化虽然必要，但使得依赖旧版本号字符串的库受到困扰。一些广为人知的大库能够及时适应这种变化，但一些小型的、未经认证的库则常常在调用时抛出"非法版本号9.0.0.4"的错误，而且往往找不到人修复。
在Java 8之前，反射没有严格的限制，使得用户可以随意访问JVM的底层。这导致了诸多项目在升级Java 9时遇到了问题，例如调用私有API或者通过反射修改JVM初始化时的环境变量。这些操作在升级之前是无法预知的，就像是在升级路上埋设的地雷，使得升级过程变得异常复杂。
Java 9对反射添加了限制，但原计划在Java 9中全面限制反射的计划因影响过大而未能实施。其他一些操作，如通过反射调用私有API或使用Unsafe.defineClass，也在Java 11中被禁止。这些方法通常被大公司生产的有售后服务的库所使用，因此能够得到解决。然而，当将一个库从较旧版本升级到较新版本时，问题就出现了。一些小型库可能会出现找不到特定方法（如Unsafe.defineClass）的问题。
在成功升级到Java 9后，我们试图进一步升级到Java 10。然而，遇到了IntelliJ IDEA的一个bug，该IDE错误地理解了一个尚未生效的草案JEP182，导致编译器给出了不正确的结果，我们花费了大量时间才找到问题的根源。这表明即使在大型公司中，兼容性问题也可能在升级过程中出现。
业界的许多工具不支持Java 9，FindBugs就是其中的一个例子。幸运的是，SpotBugs承担了FindBugs的职责。对于小型库而言，这种情况尤其令人头疼，因为Java生态系统在过去十年中得到了迅速发展。使用了不规范库的项目可能需要花费几天时间进行调试和解决兼容性问题。
对于升级到Java 9/11，最关键的一点是确保代码有完善的自动化测试覆盖。这使得我们能够自信地说，升级已成功完成。然而，对于没有测试覆盖的旧代码，升级后的稳定性和可靠性就难以保证。因此，对于没有测试覆盖的项目，升级需要谨慎行事。
升级到Java 9/11并不是什么困难的任务，但需要投入大量时间和精力。对于成熟的公司来说，代码是辅助业务的手段而非目标，因此在没有明确利益保证的情况下，升级的意愿可能不会很强。总的来说，升级Java版本需要权衡时间、资源和潜在的收益，确保在进行升级时，项目的稳定性和可靠性得到充分保障。2024-11-02
