17370845950

旧项目能否运行取决于编译参数与运行环境的匹配：需用-source/-target或更安全的-release指定兼容版本，并在目标JRE上实测。

旧项目还能不能跑，取决于 source 和 target 编译参数

JDK 升级本身不强制破坏旧项目，真正决定能否编译通过的是编译器对源码语法和字节码版本的要求。比如用 JDK 17 编译一个只含 ArrayList 和 for 循环的 Java 8 项目，默认会生成 class 文件版本 55（对应 JDK 11），但旧 JVM 可能只支持到 52（JDK 8）。

关键不是“装了新 JDK”，而是构建时是否显式控制了兼容性：

• javac -source 8 -target 8：告诉编译器按 Java 8 语法解析，并生成 Java 8 字节码
• Maven 用户需在 pom.xml 中配置 maven-compiler-plugin 的 source 和 target（或 release）
• Gradle 用户应设 java.sourceCompatibility = JavaVersion.VERSION_1_8 并启用 release 模式（更安全）

release 参数比 source/target 更可靠

-source 和 -target 只控制语法和字节码版本，不校验 API 调用是否越界。比如在 JDK 17 下用 -source 8 -target 8 编译，仍可能无意调用 String.isBlank()（Java 11 新增），运行时抛 NoSuchMethodError。

-release 8 则严格限制：只允许使用 JDK 8 的标准库符号，且生成兼容 JDK 8 的字节码。这是 JDK 9 引入的安全机制，推荐所有跨版本构建场景启用：

• Maven 示例：

  
    org.apache.maven.plugins
    maven-compiler-plugin
    3.11.0
    
      8
    
  

• 命令行直接使用：javac -release 8 Main.java
• 注意：-release 不支持低于 JDK 9 的编译器，且不能与 -source/-target 混用

运行时兼容性要看 JRE 版本，不是 JDK

编译通过 ≠ 运行成功。旧项目打包成 jar 后，最终在哪个 JRE 上执行，决定了能否加载类、调用方法、反射访问字段。

常见陷阱：

• 用 JDK 17 编译但未设 -release，又用了 var 或 switch 表达式（Java 14），即使生成了 Java 8 字节码，语法层面已非法
• 依赖的第三方库（如 guava、spring-core）本身要求最低 JRE 版本，比如 Spring Boot 3.x 强制要求 JRE 17+
• 系统属性、安全管理器、JNI 调用等底层行为在不同 JDK 版本中可能变更，需实测

建议上线前，在目标生产环境的最小 JRE 版本上做完整集成测试，而非仅依赖本地编译结果。

多 JDK 共存时，IDE 和构建工具容易默认用错版本

IntelliJ / Eclipse / VS Code 都可能缓存旧的 JDK 配置；Maven 默认读取 $JAVA_HOME，但项目级 .mvn/jvm.config 或 MAVEN_OPTS 可能覆盖它；Gradle 的 gradle.properties 中 org.gradle.java.home 优先级更高。

排查步骤：

• 检查构建日志开头是否输出类似 Java version: 17.0.1, vendor: Oracle Corporation
• Maven 执行 mvn -v 看实际生效的 JDK
• 在代码里加 System.out.println(System.getProperty("java.version")) 确认运行时版本
• IDE 中逐层确认：Project SDK、Module SDK、Project bytecode version、Maven runner JDK

别假设“我装了 JDK 17，项目就自动升级了”——绝大多数旧项目需要手动锁定版本，否则某次 clean rebuild 就可能悄悄引入不兼容变更。