Netflix 从 Java 8 迁移到 11 的案例研究心得： “我的方法和他们的方法之间的唯一区别是没有绝望。”
在过去的两年里，我做了一件没有人认为不可能的事情。我将我们的代码从 JDK 8 更新到 JDK 16。在我在 Netflix 完成的所有事情中，这是我问得最多的一件事，也是最令人惊讶的一件事。“你是怎么做到的？”
当我加入 Netflix 时，没有人告诉我从 Java 8 升级到 11 是不可能的。我刚刚开始使用它。当事情在 11 版本不起作用时，我去检查是否需要更新库。我在我自己的机器上将它作为一个次要项目进行，与主存储库分开。将所有非工作库一一更新为工作库。当一个库与 Java 11 不兼容时，我在 GitHub 上提交了一个 PR 来修复它。而且，听起来很简单，当没有更多破碎的东西时，只剩下工作的东西！
直到我将这些更改推送到生产环境后，我才发现我所做的事情是不可能的。很多人问我是如何做到这一点的。某个人或某个团体看到了更新数百个项目和可能还有数百个库的艰巨任务，并已经放弃了希望。我的方法和他们的方法之间的唯一区别是没有绝望。
如果您不熟悉 Java，Oracle 做出了一个艰难的决定来实现 Java 现代化。在 Java 9 之前，每隔几年就会发布一个主要版本，并且有相对较小的重大更改。所有这些在 Java 9 中都发生了变化；主要版本将被打破，每 6 个月发布一次。
但是，与 Python 3000 不同的是，Java 的重大更改极其有限。只有 JVM 内部会被限制或删除。就是这样。所有现有的语言功能仍然可以使用。所有 JVM 字节码和类仍然有效。想使用 1995 年编写的类吗？如果它不依赖于sun.*代码，那很好！但是，这也是很多人认为升级不可能的原因。大量的 Java 代码随意使用了 JDK 内部结构。
由于没有 API 边界，Java 8 几乎可以让应用程序和库所有者做他们想做的事。Guice、Guava、Jackson、Groovy、Gradle、CGLib、Mockito、Lombok、ErrorProne 和其他常见的 Java 技术与 JVM 的胆量一起玩得不亦乐乎。是的，他们的代码更快。但不，这不是一场长期的胜利。
这就是从事 Java 工作的人做出的艰难决定发挥作用的地方。Java 可以改进自身、添加功能和改进 VM，但代价是破坏生态系统。
有两点让我印象深刻：
- 拥有强大的、可执行的 API 边界对于长期改进是必要的。短期胜利虽然诱人，但通常伴随着非标准或不受支持的行李。今天越严格，未来就越容易维护。
- 取消一些功能，即使在标准或规范的支持下，也会变得有害。如果它曾经有效，而你破坏了它，那是你的错。