Ubuntu Java编译时版本冲突怎么办
在日常开发中，相信不少同行都遇到过这样的场景：系统里同时装着几个不同版本的JDK，编译时突然蹦出版本冲突的报错，或者辛辛苦苦写好的代码一运行就提示“不支持的类版本”。别急，这类问题在Ubuntu环境下其实有相当成熟的解决办法。下面我把常见的处理路径梳理一遍，从最直接的排查到彻底的容器隔离，按需取用即可。
1. 先摸清家底：查看当前安装的Java版本
动手处理之前，总得先知道自己系统里到底有哪些Java版本在“打架”。两个命令搞定：java -version查看运行环境版本，javac -version查看编译器版本。这一步没什么技术含量，但却是后续所有操作的基础——就像修车之前得先看看发动机型号一样。
2. 用update-alternatives优雅地切换默认版本
Ubuntu自带了一个非常实用的工具update-alternatives，专门用来管理系统级的默认程序版本。对于Java来说：
首先运行sudo update-alternatives --config java，屏幕上会列出当前已安装的所有JDK路径（比如/usr/lib/jvm/java-8-openjdk-amd64/bin/java），输入对应的数字就可以直接切换默认的java命令。同理，sudo update-alternatives --config javac用来切换编译器。如果系统里没有你想要的版本（比如手动解压的Oracle JDK），可以通过sudo update-alternatives --install /usr/bin/java java /path/to/new/java/bin/java 优先级把它注册进去，优先级数字越大，被选中的权重越高。
3. 环境变量手动配置：更灵活的项目级控制
系统级的切换有时不够灵活——比如你同时在开发两个项目，一个需要Java 8，一个需要Java 11。这种情况下，修改用户级的环境变量往往是更干净的做法。编辑~/.bashrc（或者是~/.zshrc，取决于你用的Shell），在末尾追加：
export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64
export PATH=$JAVA_HOME/bin:$PATH
记得把路径替换成你实际想要使用的JDK安装目录。保存后运行source ~/.bashrc使配置生效，然后用echo $JAVA_HOME和java -version验证一下。这个方法的好处是只影响当前用户，不会动系统全局设置。
4. 断舍离：卸载不需要的Java版本
如果系统里堆积了大量无用JDK（比如每次升级后都留着旧版本），不如彻底清理掉。先通过sudo apt list --installed | grep openjdk找到已安装的OpenJDK包名，然后sudo apt-get purge openjdk-8-jdk卸载指定版本，最后执行sudo apt-get autoremove清理残留依赖。版本少了，冲突的概率自然就小了。
5. 专业玩家的选择：使用版本管理工具
对于需要频繁切换多个Java版本、甚至同时维护Kotlin/Scala等JVM语言项目的开发者，手动改环境变量显然不够高效。这时候可以借助第三方工具来“管”住JDK。
SDKMAN 是Unix生态里最流行的方案之一。一行命令curl -s "https://get.sdkman.io" | bash完成安装，然后source "$HOME/.sdkman/bin/sdkman-init.sh"激活。之后通过sdk install java 11.0.24-open安装指定版本，用sdk use java 11.0.24-open随时切换。它还会自动帮你配置好环境变量，省心不少。
jEnv 则更轻量，特别适合习惯命令行的用户。安装方式：git clone https://github.com/jenv/jenv.git ~/.jenv，然后在~/.bashrc里加上export PATH="$HOME/.jenv/bin:$PATH"和eval "$(jenv init -)"。用jenv add /usr/lib/jvm/java-11-openjdk-amd64注册版本，jenv global 11.0.24设定全局版本。两个工具选哪个？SDKMAN更全功能，jEnv更小巧，看个人偏好。
6. 编译时“强行”指定版本：不动系统，只改参数
有些时候你并不想改变系统的默认Java设置，只是为了某个特定的编译任务临时使用不同标准。这时可以直接在javac命令里加上-source和-target参数：javac -source 1.8 -target 1.8 YourClass.java。这样做相当于告诉编译器“请按Java 8的规范来解析和生成字节码”。
如果项目使用了构建工具，配置就更简单了。Maven项目在pom.xml的properties标签里写：
1.8
1.8
Gradle项目则在build.gradle里写：
sourceCompatibility = '1.8'
targetCompatibility = '1.8'
这种方式不会影响系统全局，只针对当前项目生效，非常适合团队协作中统一编译标准。
7. 终极方案：用Docker容器隔离环境
如果你的项目对Java版本有极端严格的要求（比如老旧的遗留系统必须用Java 8，而新项目必须用Java 21），或者你不想让任何系统级别的改动影响到其他工作，那么Docker是完美的答案。一条命令拉取镜像：docker pull openjdk:11-jdk。然后运行容器并进入交互环境：docker run -it --rm openjdk:11-jdk bash。在容器内部，你可以随意编译、运行，所有操作都和宿主机完全隔离。而且Docker镜像可以明确锁定JDK版本，团队里每个人拉下来的环境完全一致，再也不会出现“我电脑上能跑”的尴尬情况。
