如何为JDK17的javax.tools.JavaCompiler提供不同Java类库？

问题根源 #

JDK 9及以上采用模块化架构，核心类（如java.nio.file.Path）属于系统模块而非普通JAR，直接通过-classpath添加jrt-fs.jar无法让编译器加载高版本JDK的类定义——jrt-fs.jar仅用于访问模块内容的文件系统，不包含类本身。而var类型推断失败只是表象，本质是编译器找不到JDK23新增的resolve(String,String)方法签名。

可行解决方案 #

方案1：直接使用目标版本JDK运行解析程序 #

这是最简单且最可靠的方式：将你的解析程序切换到JDK23环境下运行。此时ToolProvider.getSystemJavaCompiler()会获取JDK23的编译器实例，天然支持该版本的所有类方法，无需额外配置。

方案2：在JDK17环境中指定目标JDK的系统模块 #

如果必须在JDK17进程中运行，可通过javac的--system参数指定目标JDK的根目录，让编译器使用该版本的系统模块进行解析：

修改你的编译器参数配置：

// 替换为你的JDK23安装路径
String targetJdkHome = "/path/to/jdk23";
List<String> opts = Arrays.asList(
    "--system", targetJdkHome,
    "-encoding", "UTF-8"
);

• --system参数会让javac忽略当前运行时的JDK模块，转而使用指定JDK目录下的系统模块集合（即lib/modules文件）。
• 这样编译器就能找到JDK23中Path类的resolve(String,String)方法，进而完成var的类型推断。

关键说明 #

• 为什么-classpath对JUnit有效？JUnit是普通JAR（或兼容类路径加载的模块化JAR），可通过类路径直接加载；但JDK核心类属于系统模块，必须通过模块化参数（如--system、--module-path）才能让编译器正确识别。
• 避免直接加载高版本JDK的tools.jar或模块：跨版本调用编译器内部API可能引发兼容性问题，优先采用上述两种方案。

内容的提问来源于stack exchange，提问作者YellowDog