StandardJavaFileManager 不负责编译，仅作为文件管理接口配合 JavaCompiler 使用；真正编译由 getTask() 创建的任务执行，需正确配置源码、输出路径、编码等参数，并注意 JDK 版本兼容性与内存编译细节。

不能直接用 StandardJavaFileManager 动态编译 Java 源码——它只是个文件管理接口，不负责编译逻辑。

为什么 StandardJavaFileManager 本身不编译代码

它是 javax.tools.JavaCompiler 的配套组件，只管“怎么找源文件、怎么写 class 文件、怎么处理编码”，类似一个带规则的文件系统抽象层。真正干活的是 JavaCompiler.getTask() 返回的编译任务。

• 常见错误现象：StandardJavaFileManager 没有 compile()、run() 这类方法，硬调会编译失败或报 NullPointerException
• 使用场景：它必须和 JavaCompiler 配合，比如指定源路径、输出目录、字符集，或把内存中的字符串当作“虚拟源文件”喂给编译器
• 参数差异：它的 getJavaFileObjectsFromFiles() 和 getJavaFileObjectsFromStrings() 返回的是 JavaFileObject，这才是编译器能吃的输入格式

动态编译必须走 JavaCompiler.getTask() 流程

核心链路是：获取编译器 → 创建 file manager → 构造 source objects → 调 getTask() → call() 执行。

java-api-doc-generator

分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。

下载

• 关键步骤：
  • 用 ToolProvider.getSystemJavaCompiler() 拿到编译器（注意：JRE 运行时可能没带 tools.jar，得用 JDK 启动）
  • 用 compiler.getStandardFileManager() 创建 manager，别自己 new
  • 源码是字符串？用 fileManager.getJavaFileObjectsFromStrings() 包装；是 .java 文件？用 getJavaFileObjectsFromFiles()
  • getTask() 的第 4 个参数是 options，比如 -d 指定输出目录，-source 控制语法版本，漏掉会导致 class 写到当前目录或编译失败
• 性能影响：每次调 getTask() 都新建上下文，频繁编译建议复用 StandardJavaFileManager（但注意它不是线程安全的）
• 兼容性坑：Java 9+ 默认模块系统下，tools.jar 已整合进 jdk.compiler 模块，需加 --add-modules jdk.compiler 启动参数，否则 getSystemJavaCompiler() 返回 null

绕过文件系统：用 JavaFileObject 实现内存中编译

想把字符串源码直接编译、不落地 .java 文件？必须自定义 JavaFileObject 子类，重写 getCharContent() 和 openOutputStream()。

立即学习“Java免费学习笔记（深入）”；

• 容易踩的坑：
  • 忘记在 getKind() 里返回 Kind.SOURCE，编译器会跳过该文件
  • toUri() 返回的 URI 必须有 scheme（如 mem:///A.java），否则 manager 找不到文件
  • 输出流写完后没 close，class 字节码可能截断，后续 ClassLoader 加载时报 ClassFormatError
• 示例片段（简化版）：

  public class InMemoryJavaFileObject extends SimpleJavaFileObject {
    private final String code;
    protected InMemoryJavaFileObject(String name, String code) {
      super(URI.create("mem:///" + name + Kind.SOURCE.extension), Kind.SOURCE);
      this.code = code;
    }
    @Override
    public CharSequence getCharContent(boolean ignoreEncodingErrors) {
      return code;
    }
  }

真正难的不是调通流程，而是让编译器在各种 JDK 版本、不同启动方式（IDE、jar、容器）、不同 classpath 下稳定吐出可加载的字节码——StandardJavaFileManager 只是其中一环，但它一旦配错路径或编码，后面全崩，而且错误信息往往藏在 DiagnosticCollector 里，不显式打印就根本看不到问题在哪。