旧项目能否运行取决于编译参数与运行环境的匹配：需用-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 版本中可能变更，需实测
多 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
