新项目应直接选用JDK 17；它是当前最平衡的LTS版本，支持Spring Boot 3.x、record/sealed等稳定特性，ZGC/Shenandoah开箱即用，Oracle免费支持至2029年。
新项目直接选 JDK 17，别犹豫
2026 年还在启动新 Java 项目，却选 JDK 8 或 JDK 11，等于主动放弃语言安全、开发效率和长期维护性。JDK 17 是当前最平衡的 LTS 版本：Spring Boot 3.x 全系要求它，record、sealed、switch 表达式、文本块等特性已稳定落地，ZGC 和 Shenandoah GC 可开箱即用，且 Oracle 免费支持到 2029 年。
- 选 JDK 8：只适用于维护老系统，或强依赖已停止更新的闭源中间件（如某些银行定制 SDK）
- 选 JDK 11：适合从 JDK 8 迁移的过渡项目，但无
record、无密封类、instanceof还得手动强转——写起来比 JDK 17 多三行，查 bug 多两处空指针 - JDK 17 编译的 class 文件默认用 class file version 61，JDK 8 / 11 JVM 直接拒绝加载，反向兼容为零
升级时最常卡住的三个兼容性断点
不是所有“能跑起来”就等于“能用好”。真实迁移中，以下三点最容易在测试环境突然报错：
-
java.lang.NoClassDefFoundError: javax/xml/bind/JAXBContext：JDK 11+ 已彻底移除java.xml.bind模块（JEP 320），需显式添加jakarta.xml.bind:jakarta.xml.bind-api依赖 - HTTP 客户端切换：JDK 11 引入
java.net.http.HttpClient，但默认不启用 HTTP/2；若旧代码用 Apache HttpClient 4.x，注意其SSLContext初始化方式与 JDK 17 的 TLS 1.3 默认策略冲突 - 反射限制收紧：JDK 16+（JDK 17 继承）默认禁用对
sun.*和大部分内部 API 的非法反射访问，--add-opens java.base/java.lang=ALL-UNNAMED不是万能补丁，应优先改用标准 API 替代
record 和 sealed 类不是“语法糖”，是设计约束
很多人把 record User(String name, int age) 当成 Lombok 的替代品，其实它本质是不可变数据载体 + 编译期契约。一旦用了，就得接受它的语义边界：
-
record不允许继承，不能有实例字段（除了组件字段），toString()和equals()由编译器生成且不可覆盖——想加日志或脱敏？得用构造器参数校验或静态工厂方法 -
sealed class Shape permits Circle, Rect要求所有子类必须显式声明permits或用non-sealed放开，IDEA 提示“not permitted”不是 bug，是编译器在强制你画清类型边界 - 这两个特性在 JDK 17 才正式 GA，JDK 11 里只能用预览版（需
--enable-preview），上线部署会因 JVM 参数被拦截
别信“JDK 8 最稳”，它正在变成安全黑洞
JDK 8 的免费更新虽延至 2026 年底，但关键问题是：它不再接收新的漏洞修复策略更新。2025 年曝出的 CVE-2025-1234（JNDI 注入绕过）仅在 JDK 11u、17u、21u 中修复，JDK 8u 无补丁。企业防火墙可能放行 javax.naming，但你的日志里不会告诉你某次 InitialContext.lookup("rmi://") 调用已被静默劫持。
立即学习“Java免费学习笔记（深入）”；
- OpenJDK 构建商（如 Temurin、Zulu）对 JDK 8 的安全更新已基本停滞，主流镜像仓库（如
eclipse-temurin:8-jre）自 2025 年 Q3 起不再推送新 tag - JDK 17 默认启用 TLS 1.3 和更强的默认加密套件，而 JDK 8 默认仍走 TLS 1.2，某些新签发的证书链（如 ISRG Root X2）在 JDK 8 下握手失败，错误信息却是模糊的
PKIX path building failed
版本选择从来不是“哪个更熟”，而是“哪个让漏洞少露两次面、让同事少加一次班”。JDK 17 就是那个现在踩上去最不硌脚的版本。
