昨天在群里跟大家聊了聊，我想把这个消息跟各位也分享一下，Jenkins 要升级到 Java 17 了，别再盯着 Java 8 不放啦。其实官方早就发话了，从去年 6 月 28 日发布的 2.357 LTS 版本开始，人家就把最低要求定在了 Java 11。按照这个节奏，9 月的 LTS 版肯定也会要求 Java 11，这就意味着大家手里的 Jenkins 要是还跑在 Java 8 上，那升级就不再是“要不要”的选择题，而是“必须要”的必答题。 大家都知道 Jenkins 以前叫 Hudson，这玩意儿从 2005 年刚出来的时候就经历了好几轮 Java 版本的大换血。现在大伙儿都达成共识了，觉得从 Java 8 往 11 走的这一段路和项目的历史发展简直一模一样。换句话说，代码库里的东西早就准备好了，真正要折腾的是本地跑的那个 Jenkins 实例，还有你那个 Docker 镜像。 咱也别再死磕 Java 8 了，这真不是个明智的选择。那位开发者 Basil Crow 在博客里掰扯得很清楚，三大硬伤摆在那儿：安全补丁断了线，像 Jetty、JGit、Spring Framework、Spring Security 这些关键库早就宣布放弃 Java 8 了；性能和内存都不如人家了，LinkedIn 和 Adoptium 那边做过实验，Java 11 启动快、占内存少；人才流失风险也不小，现在的年轻程序员都愿意在新环境里干活，“老旧标签”会把招人和留人的成本无形中抬高。 说到 Docker 那边早就走在了前面。官方镜像早就全面换成了 Java 11，Java 8 只留下做个备胎用了。至于 Java 17，官方是以预览模式悄悄上架的。从 2.357 版本开始，官方就要把 Java 8 的镜像彻底淘汰了。团队说了句大实话：“与其等到出事再去救火，不如提前挪到 Java 17 上去。” 大家心里肯定也在打鼓，从 Java 11 升到 17 会不会特别麻烦？我告诉大家不用担心。社区的实测数据很说明问题，这次升级的难度比从 8 升到 11 小多了。原因有三条：类图和 API 的兼容性比之前强；新版 JVM 对垃圾收集器做了不少优化，GC 日志看着更顺眼了；Jenkins 自带的那个插件兼容性检查脚本特别好使，能自动帮你找出那些不听话的插件，大大降低了踩坑的概率。一句话总结就是：早动手早省心。 具体怎么操作呢？这里给大家划个重点：用 Docker 升级的话，总共就三步。第一步是把最新的镜像给拉下来；第二步是重置一下数据卷（这一步看情况选不选），要是怕旧数据捣乱，最好先备份再重新建个卷；第三步是去系统管理里检查插件兼容性，把不支持 Java 17 的插件禁用或者换掉。 最后咱们来个小总结：升级路线图得看清楚。赶紧停掉新建 Java 8 环境的想法；生产环境建议直接跳过 11 版直奔 17 版；预览模式现在用着已经够了；如果想换个稳定的 GA 版随时都能切过去；记着用 StopWatch 代替 System.currentTimeMillis 这种老掉牙的写法。——升级不是单纯换个 JDK 的事儿，而是要换种思维去看问题。 对了还有个好消息补在最后：昨天有个留言活动送设计模式书的事儿给忘了，现在大家可以重新在评论区说说你在做“Jenkins 多分支流水线”时最头疼的那个场景，我来抽三位送《23 种设计模式实战》。书单一直都在更新里呢，大伙儿记得盯着点别错过啦！