在 WSL2 和 Ubuntu 下使用 SDKMAN 管理多版本 Java

• 当前 shell 立刻使用 Java 17
• Maven、脚手架、命令行工具都会跟着用这一套 JDK

如果想把某个版本设成「默认版本」（全局默认），可以用：

sdk default java 17.0.10-tem

五、核心功能：项目级 Java 版本固定（强烈推荐）

这一块基本是 SDKMAN 的「杀手级」功能：让每个项目有自己的 Java 版本配置。

1. 进入项目目录

cd ~/project/mom/admin

2. 初始化项目环境

sdk env init

执行后，项目根目录下会生成一个 .sdkmanrc 文件。

3. 编辑 .sdkmanrc

nano .sdkmanrc

写入你想绑定的 JDK 版本，例如：

java=17.0.10-tem

保存退出即可。

4. 启用项目级 Java 版本

在项目目录中执行一次：

sdk env

或者直接开启自动模式（推荐）：

sdk config set sdkman_auto_env true

之后的体验就是：

• 每次 cd 进该项目目录，Java 自动切到 17
• 离开目录，Java 自动恢复为全局默认版本

多项目并行开发时，这一点可以极大降低「切错 JDK」导致的各种莫名报错。

六、SDKMAN + Maven + 工具的实际效果

在项目目录中执行：

java -version
mvn -v

通常会看到：

• java 版本就是 .sdkmanrc 中配置的那一套
• mvn 使用的是同一套 JDK（JAVA_HOME 由 SDKMAN 管理）

此时，让脚本或工具去执行 mvn compile，就不会再遇到类似：

invalid target release: 17

这类因为 JDK 不匹配导致的构建错误，也不需要手动调环境变量、改 IDE 里的 JDK 配置。

七、对比常见几种方案

下面简单对比一下几种常见的多 JDK 管理方式：

在 WSL2 / Ubuntu 环境下，SDKMAN 的易用性和可维护性基本是完胜。

八、实践中的一些小建议（踩坑总结）

结合实际踩坑经验，有几条可以直接遵循：

• 让「Java 版本随项目走」，不要随系统走
• 老项目固定在 Java 8，新项目用 Java 17 / 21，可以长期共存
• 用 SDKMAN 统一管理 JDK，多 Maven 版本的话可以配合 Maven Toolchains 兜底
• 尽量避免再手动改 JAVA_HOME 等系统环境变量

如果你同时在用：

• Maven / Gradle
• Spring Boot / 微服务项目
• 多个项目并行开发（单体 + 微服务 / 新老系统）
• 甚至本地脚本、自动化工具

那么「SDKMAN + 项目级 .sdkmanrc」会让环境切换这件事变得非常顺手。

九、最后的一句话总结

在 WSL2 / Ubuntu 下做 Java 开发，SDKMAN 基本可以视为多版本 JDK 管理的「默认解」。

只要把「每个项目都配一份 .sdkmanrc」养成习惯，环境切换这件事基本就从你的日常心智负担里消失了。