在 Ubuntu 上做 Java 开发时，最常见的一类环境问题，就是项目要求的 JDK 版本和系统当前使用的版本对不上。表面上看是编译失败，实际往往涉及系统默认 Java、构建工具配置、IDE 运行时甚至旧字节码残留几个环节。
这篇文章按排查顺序把处理方法拆开：先确认当前编译器和运行时版本，再决定是切系统默认版本，还是用 jenv、sdkman 这类工具做多版本管理，最后回到 Maven、Gradle 和 IDE 配置里把项目要求统一起来。照着走一遍，基本就能判断问题究竟出在系统环境，还是出在项目配置本身。
先确认当前使用的是哪个 Java 版本
遇到“项目要求 Java 11，但 Ubuntu 默认还是 Java 8”这类情况，第一步不是直接重装，而是先看清楚当前编译器和运行时分别指向哪里。
可以先执行下面两条命令：
ja vac -version
ja va -version这里的重点是分别确认 ja vac 和 ja va 的版本。两者不一致时，编译和运行可能会出现两套不同的问题；如果版本本身低于项目要求，就需要安装目标 JDK 并切换默认设置。
需要多版本时，先把目标 JDK 装齐
如果你的机器上只装了一个旧版本 JDK，而手头项目又要切换 Java 8、Java 11 甚至更高版本，比较稳妥的做法是把常用版本都装好，再决定怎么切换。
以 OpenJDK 为例：
sudo apt update
sudo apt install openjdk-8-jdk # 安装Ja va 8
sudo apt install openjdk-11-jdk # 安装Ja va 11安装完成后，可以再用 ja va -version 检查当前默认运行时版本是否发生变化。这里要注意，装上多个 JDK 并不等于系统已经自动切换到你需要的版本，后面还需要继续配置。
用 update-alternatives 切换 Ubuntu 默认 JDK
如果你只是想把系统默认的 Java 和 javac 切到指定版本，Ubuntu 自带的 update-alternatives 通常已经够用。
执行下面两条命令，系统会列出可选版本编号，按提示选择即可：
sudo update-alternatives --config ja va
sudo update-alternatives --config ja vac切换完成后，建议立即再次验证：
ja va -version
ja vac -version如果这里显示的版本已经和项目要求一致，说明系统级默认 JDK 已经调整好了。对只维护单个项目，或者所有项目都统一升级到同一版本的场景，这种方式最直接。
项目经常切换版本时，用 jenv 或 sdkman 更省事
如果你同时维护多个项目，而且它们对 Java 版本要求不同，那么每次改系统默认版本会比较麻烦。这种情况下，更适合用 jenv 或 sdkman 做按项目、按终端的切换。
jenv：适合管理本机已安装的多个 JDK
先安装 jenv：
git clone https://github.com/jenv/jenv.git ~/.jenv
echo 'export PATH="$HOME/.jenv/bin:$PATH"' >> ~/.bashrc
echo 'eval "$(jenv init -)"' >> ~/.bashrc
source ~/.bashrc然后把已经安装好的 Java 版本加入 jenv：
jenv add /usr/lib/jvm/ja va-8-openjdk-amd64
jenv add /usr/lib/jvm/ja va-11-openjdk-amd64切换时可以按范围选择：
- 全局切换：
jenv global 11.0.24 - 当前终端临时切换：
jenv shell 8.0.422
它的优点是不会频繁改系统全局配置，适合本机已经装了多个 JDK 的开发环境。
sdkman：适合安装并切换指定 Java 发行版
如果你希望从安装到切换都交给同一套工具管理，sdkman 会更顺手。
先安装 sdkman：
curl -s "https://get.sdkman.io" | bash
source "$HOME/.sdkman/bin/sdkman-init.sh"安装指定版本：
sdk install ja va 11.0.11-open切换方式如下：
- 当前会话临时切换：
sdk use ja va 11.0.11-open - 设为默认版本：
sdk default ja va 11.0.11-open
如果你经常测试不同发行版和补丁版本，sdkman 的管理体验通常会更灵活一些。
系统版本对了，还要检查项目构建配置
很多时候，系统里的 Java 已经切到了正确版本，但项目仍然报错，原因是构建工具里写死了错误的 source/target 配置，或者 IDE 仍在使用旧运行时。
Maven 项目怎么指定编译版本
如果是 Maven 项目，可以在 pom.xml 中明确指定编译版本：
<properties>
<ma ven.compiler.source>11</ma ven.compiler.source>
<ma ven.compiler.target>11</ma ven.compiler.target>
</properties>这一步的作用是让 Maven 编译过程与项目目标版本保持一致，避免系统 JDK 已切换，但 Maven 仍按旧配置编译。
Gradle 项目怎么统一 sourceCompatibility
如果用的是 Gradle，可以在 build.gradle 中添加：
ja va {
sourceCompatibility = Ja vaVersion.VERSION_11
targetCompatibility = Ja vaVersion.VERSION_11
}这里同样是在告诉构建系统：源码级别和目标字节码版本都按 Java 11 处理。
别忽略 IDE 的 Java Runtime 配置
即使命令行和构建工具都调整好了，IDE 仍可能继续调用旧 JDK。比如在 VSCode 里，可以按 Ctrl+Shift+P 搜索“Ja va: Configure Ja va Runtime”，再手动选择对应版本。
如果你是在 IDE 里编译通过、命令行失败，或者反过来命令行正常但 IDE 一直报错，通常就要优先检查这里。
切换版本后，先清理旧产物再重新编译
Java 版本切换之后，残留的 .class 文件或旧的构建目录，经常会让问题看起来像“明明改对了还是报错”。这类情况需要先清理，再重新构建。
可以先删除常见编译残留：
rm -rf target/ *.class然后重新编译：
ja vac -source 11 -target 11 YourClass.ja va如果项目本身已经接入构建工具，通常直接执行下面的命令更稳妥：
mvn clean compile
gradle build这样可以让依赖解析、编译参数和输出目录都由项目配置统一接管，减少手工编译带来的偏差。
最后一步：验证是否还有依赖兼容性问题
当系统默认版本、版本管理工具、构建配置和 IDE 都已经对齐后，还需要做最后一次验证：重新运行项目或测试用例，确认错误是否已经消失。
如果仍然存在版本相关异常，就要继续排查依赖库本身是否支持当前 JDK。对于 Maven 项目，可以先查看依赖树：
mvn dependency:tree如果某些依赖只支持更低版本 Java，即使你的环境切换正确，编译或运行阶段仍然可能失败。到了这一步，问题通常已经不在 Ubuntu 系统配置，而在项目依赖和升级策略本身。
