Java编译器_Java编译器工作原理与选择指南_技术教程

javac是JDK自带的标准Java编译器，负责将.java编译为.class字节码，但不参与运行时、不自动处理模块路径、无增量编译能力，也不读取构建配置文件；真正控制编译流程的是构建工具或IDE的配置。

Java编译器不是“选一个就好”的工具——javac 是标准，但实际构建中你真正调用的可能是 ecj、zinc 或 Gradle 封装后的编译逻辑。关键不在“用哪个”，而在“谁在控制编译流程、何时触发、是否跳过或增量编译”。

javac 是 JDK 自带的标准 Java 编译器，将 .java 源文件编译为 JVM 可执行的 .class 字节码。但它不参与运行时、不解析注解处理器（除非显式启用）、也不自动处理模块路径（--module-path 需手动指定）。

它默认只做语法检查 + 语义分析 + 字节码生成，不执行任何优化（如内联、逃逸分析），那是 JIT 的事
它不缓存中间结果，每次调用都是从头编译；没有内置增量编译能力
它不读取 pom.xml 或 build.gradle，Maven/Gradle 调用它时会先解析依赖并拼出完整的 -cp 或 --class-path
常见错误：error: class, interface, or enum expected 往往不是 javac 本身问题，而是编码格式（如 UTF-8 with BOM）、行结束符（CRLF vs LF）或源文件混入不可见控制字符导致

IntelliJ 和 Eclipse 默认使用自己的编译器：IntelliJ 用 javac 包装层（支持即时编译反馈），Eclipse 则用 ecj（Eclipse Compiler for Java）。它们都能在编辑时实时报告错误，而原生 javac 必须等保存+手动运行命令。

ecj 允许语法宽松（比如字段初始化时调用未定义方法，只报 warning），javac 则直接拒绝编译
IDE 编译输出目录（如 out/production）和构建工具（如 Gradle 的 build/classes/java）通常不同，切勿混用
若在 IDEA 中看到 Cannot resolve symbol XXX，先检查是否启用了 Build project automatically，而非怀疑 javac 版本
Gradle 构建时可通过 compileJava.options.fork = true 强制走独立 JVM 进程调用 javac，用于隔离内存或诊断类加载冲突

不必完全一致，但有明确约束：source、target（旧版）或

--release（推荐）必须匹配目标运行环境的 Java 版本能力。

javac -source 17 -target 17 表示允许使用 Java 17 语法，并生成兼容 Java 17 JVM 的字节码
javac --release 11 更严格：禁用所有 Java 11 之后新增的 API（如 String.isBlank() 在 11 才引入），避免 NoSuchMethodError
用高版本 javac 编译低版本字节码（如 JDK 21 的 javac 加 --release 8）是安全的；反过来则不行（JDK 8 的 javac 不认识 var 关键字）
Spring Boot 3 要求最低 Java 17 运行时，但如果你用 JDK 21 编译并设 --release 17，仍可部署到 Java 17 环境，且不会意外引用 JDK 21 特有 API

Gradle 和 Maven 在多次构建间会跳过编译阶段，不是因为编译器快，而是靠时间戳和输入哈希判断源码/依赖是否变更。一旦你手动修改 .class 文件或清空 build/ 目录却不清理缓存，就可能触发“编译了但没生效”的假象。

Gradle 默认开启 buildCache 和 configure on demand，若想强制重编译，用 ./gradlew clean compileJava，而不是只跑 compileJava
Maven 的 maven-compiler-plugin 若未声明和，会降级使用 JDK 的默认值（例如 JDK 17 下默认为 17），容易在 CI 环境因 JDK 版本差异导致行为不一致
使用 Lombok 时，javac 实际执行的是带 annotation processor 的编译流程，若 lombok.jar 未正确放在 -processorpath，就会出现“注解没生效”但无报错的情况
Android 开发中 javac 输出的 class 会被 d8（或旧版 dx）再转换成 .dex，这个环节失败时错误日志往往指向 d8，而非 javac