Java17已经出现一年了，为什么仍然有那么多的公司使用Java11 甚至 Java8？

Java17 自2021年9月14日发布以来已经一年的时间了，使用JDK8的小伙伴仍然有很多，是什么原因导致那么多的用户不愿意升级Java版本？

 

• 你所使用的JDk开发版本是由你需要支持的最老的系统决定的，而不是最新的系统。有时，它可能会令人惊讶地古老。
• 平台升级总是有风险的。很早以前我将一个系统从Java 5升级到了Java 6，它破坏了JBoss。事实证明，那个版本的JBoss依赖于核心API返回的数组中值的顺序。API没有承诺任何特定的顺序，但JBoss实现假设顺序总是相同的。它在Java 6中发生了变化，并迫使人们对自己的配置文件进行一些更改，以便启动JBoss。这令人惊讶，因为从5到6的过渡本该是无缝的。
• 从Java 8到Java17的过渡并不是无缝的，因为在9-10-11版本中有很多变化。这就是为什么许多项目都坚持使用Java 8的主要原因。Java承诺“一次编写，到处运行”，但它并没有完全实现“永远运行”。

• 以下是主要的转变:

  （1）.Java 1.4到Java 5:在Java 5中，类字面量成为了jvm级别的实体。在Java 1.4中，当你引用一个类文字时，它会执行一个class字节码中的forName。从Java 5开始，对类字面量的引用将从常量池加载一个对象。这就产生了一个新的情况:一个类被加载但没有初始化。一些现有的Java代码假设，当你引用类字面量时，将调用它的静态初始化式。这不再是正确的，并破坏了做这个假设的代码。

  （2）.Java 6到Java 8: Java 7 JVM引入了方法句柄作为新的JVM实体。Java编译器直到Java 8才使用它们，并在lambda表达式的实现中使用它们。所以Java 6到Java 7没有做太多的工作，但是Java 8生成的字节码有一些主要的区别。除了像JBoss这样令人惊讶的例子之外，这是对Java 5-7的无缝升级。

  （3）.Java 8到Java 9-10-11: Java 9引入了模块系统。这是一个根本性的改变，它在执行反射时引入了关于可见性的新规则。它还从核心中完全删除了一些库。Java开始遵循一种新的模式，即一个版本将更改表示为警告，下一个版本将使用禁用选项强制执行这些更改，而第三个版本将毫无例外地强制执行这些更改。从Java 8升级系统可能需要做很多工作，包括重新添加现在丢失的核心库，以及在反射中处理新的可见性规则。

  (4) . 比Java 11更好:虽然模块系统带来的巨大破坏在一段时间内不太可能再次发生(如果有的话)，但我们将看到一系列稳定的弃用和删除，Java平台将纠正一些“过去的错误”。

• 在非常严肃的软件开发世界中，只有两个月历史的东西被普遍认为是“未经验证的技术”、“重大安全问题”和“不合理的风险”。
• 关于“长期支持”、可能要到2022年底才会被考虑。就我而言，选择继续使用Java 8有点过于保守，但是，我理解这个决定。目前，可靠性和创新的最佳点(尽管对于Java开发来说这是一个强烈的词)是Java 11。
• 在过去的三年中，它已经证明了自己，它是对Java 8的一个相当不错的改进，值得一试。Java从11年到17年的发展方向是一个有趣的方向，尽管，让我们诚实地说，它似乎是Kotlin 1.0中已经存在的东西的衍生品。认为这些特性有价值的项目已经在使用Kotlin而不是Java。
• 总而言之，Java 17 LTS肯定会被考虑，只是不是现在。就像我在第一段说的，在我们考虑这个问题之前，可能要到2022年底或2023年初。
• 没有商业理由升级。好的，再详细一点:如果Java 17为他们提供了一个新特性，可以为他们节省几千元或几万元，并且节省的金钱足够多，让他们有理由去冒升级的风险——这通常随着代码库的大小而增加——那么他们就会升级。
• 为什么要“升级”到一个没什么可提供的版本?也就是说，最好的做法是及时更新安全补丁和小的改进。
• 靠炒作驱动的开发在实际的软件开发世界中是行不通的。我们需要考虑在进行升级之前是否需要升级，这可能涉及到强调优点和强调缺点的人之间进行讨论。通常兼容性不应该以任何方式牺牲，所有工作的都应该继续工作。
• 对于任何Java项目，你能保证升级始终是正确的吗?接下来，如果以上都能保证，又能带来什么呢?更好的性能吗?更经济的内存使用?如果有新的功能，会是有益的吗?如果是，以什么方式?你必须回答所有的问题，而且要令人信服。我唯一一次成功说服版本升级是当我们的代码需要剖析功能，而我们目前使用的版本不支持，我甚至尝试过由于缺少低层模块而去移植。
• 没有任何一个理智的项目经理会在新建的项目中使用最前沿的技术:风险和潜在的技术债务（程式码当中一些不寻常的地方。）是很大的。任何一个理智的公司都不会重构现有的代码库来利用最新最好的特性。技术债务是相当大的，而其影响是未知的。目前，我仍然在维护一个使用Struts 1.0的Java 1.6应用程序。这是我日常工作的一部分(1-2小时)。你不能简单地想着跳转到另一个(最新的，嗖的一下)版本，然后就期待一切都顺理成情理。保守地开发软件，不加理会语言的新特性是正确方法。
• 开发一个应用程序可能需要2到3年的时间，在这段时间内，很难不断更新到最新版本的Java，同时仍然在实现系统方面取得进展，因为你最终将花费所有的时间重构代码，以修复上次Java更新破坏的内容。因此，大多数公司在项目开始时选择Java版本，并一直使用该版本，直到主要开发完成。然后他们将更新到较新的java版本视为技术债务（Technical Debt）。
• 更新到新版本的Java通常需要更新到新版本的库，这可能会影响到大量的传递依赖性。这就需要重构代码，因为在库的新版本中所做的更改是破坏性的。即使是那些试图保持广泛兼容的库，也经常会有与旧版本不兼容的更改。所以必须测试所有内容(希望你有一个好的测试套件)。当所有的重构都完成并再次工作时，所有的东西又都过时了，因此这个循环永远不会结束。