在 Debian 系统上开展 Java 开发时，版本选择看似小事，实则暗藏玄机——版本不匹配，编译瞬间崩溃，排查半天毫无头绪。今天我将完整梳理整个流程，确保每一步都清晰明了。
1. 明确项目需求，挑选合适的 Java 版本
动手之前，先想清楚项目到底需要什么，这才是关键。千万别一上来就安装最新版，结果发现第三方库根本不支持，那就尴尬了。
- 长期维护性：如果项目要运行好几年，别盲目追求新版本，老老实实选择 LTS 版本——JDK 11、17、21 都是稳妥之选。官方至少提供 5 年安全更新和 bug 修复，企业级应用选它们准没错。
- 特性兼容性：如果项目必须使用某些新特性（比如 Lambda 表达式需要 JDK 8+，密封类需要 JDK 17+），那就选择支持该特性的最低版本。没必要为了赶时髦升级到最新版，徒增兼容性风险。
- 依赖库要求：许多第三方库（尤其是老版本的 Spring 框架）只支持特定 Java 版本。安装之前一定要仔细查阅库的文档，确认兼容范围，否则后续只能抓狂。
2. 通过系统包管理器安装基础版本
Debian 官方仓库自带 OpenJDK，作为开源实现，绝大多数场景都能满足需求。安装也非常简单：
- 先更新索引：
sudo apt update - 安装默认 JDK（通常是最新稳定版）：
sudo apt install default-jdk - 如果想装特定版本？比如 OpenJDK 11：
sudo apt install openjdk-11-jdk
安装完成后记得验证一下：java -version 和 javac -version，确保编译器和运行时版本一致。这一步经常被忽略，但一旦不一致，编译出的 class 文件可能无法正常运行。
3. 手动安装第三方版本（可选）
如果你需要 Oracle JDK，或者某些特定版本（比如 JDK 8），系统包管理器可能没有收录，那就得手动操作：
- Oracle JDK：前往官网下载
.tar.gz包，解压到/usr/lib/jvm目录下，然后使用update-alternatives配置一下即可使用。 - OpenJDK 第三方源：例如 Adoptium（原 AdoptOpenJDK），先添加它们的 APT 源，然后直接
sudo apt install temurin-<版本>-jdk。例如temurin-8-jdk就是 JDK 8。这种方法比手动解压省心得多。
4. 用 update-alternatives 管理多版本
开发环境里经常需要切换 Java 版本，Debian 自带的 update-alternatives 正是为此而生，非常好用：
- 添加版本：以 OpenJDK 8 为例，执行
sudo update-alternatives --install /usr/bin/java java /usr/lib/jvm/java-8-openjdk-amd64/bin/java 1。最后那个数字是优先级，越大越优先。 - 切换版本：运行
sudo update-alternatives --config java，系统会列出所有已注册的 Java 版本，输入对应的编号即可切换。 - 验证切换：再次执行
java -version和javac -version，确认当前版本确实已变更。建议每次切换后都验证一次，避免后续编译时莫名其妙出错。
5. 配置环境变量（可选但强烈推荐）
为了让系统全局识别 Java 路径，最好将 JAVA_HOME 环境变量配置好。否则某些工具（比如 Maven、Gradle）可能找不到 Java：
- 编辑系统级配置文件
/etc/environment，添加一行：JAVA_HOME="/usr/lib/jvm/java-11-openjdk-amd64"（路径替换为你实际安装的版本），再追加PATH="$JAVA_HOME/bin:$PATH"。 - 使配置生效：
source /etc/environment。如果只在当前用户下使用，也可以添加到~/.bashrc中，然后source ~/.bashrc。后者更灵活，不会干扰系统全局设置。
6. 验证编译兼容性
最后一步，也是最容易翻车的一步。编译 Java 程序时，必须确保编译器版本与源代码版本匹配：
- 如果源代码是用 Java 8 编写的，那么编译时一定要指定版本：
javac -source 1.8 -target 1.8。否则编译器默认使用自身版本，遇到新语法就会报错——比如在 JDK 17 上编译 Java 8 代码，突然冒出“switch 表达式”的语法错误，其实根本不是代码的问题。 - 使用 Maven 或 Gradle 的项目更简单：在
pom.xml（Maven）或build.gradle（Gradle）里配置sourceCompatibility和targetCompatibility，强制使用指定版本编译。一劳永逸，团队协作时也不怕版本不一致。
从需求分析到安装配置，再到最终的编译验证，这套流程走下来基本不会出现大问题。当然，如果遇到特殊情况，比如某个库只支持 JDK 8 但你又想用新特性，那就需要权衡一下了——要么降级语法，要么更换库，没有万能的解决方案。
