如果你同时维护多个 Java 代码库，你可能经历过这样的场景：一个服务面向 JDK 17，另一个需要 JDK 21，还有一个遗留应用只能在 JDK 11 上构建。每次切换上下文都意味着重置 JAVA_HOME 环境变量，或者记得运行版本切换命令，又或者在遇到奇怪的编译错误十分钟后才发现自己用错了 JDK。
目前已经有不少优秀的工具可以解决这一问题——SDKMAN!、jenv、asdf、mise。我使用过其中的大多数。我开发 Jolta 是因为我想要一种能够完全实现自动化的、基于项目的切换方案，尽可能减少繁琐的操作步骤，并且将 Windows 视为真正的目标平台。本文将诚实地介绍这款工具，包括在哪些情况下现有工具可能更适合你。
完全披露：Jolta 是我的项目。采用 MIT 许可证，托管在 GitHub 上的 OneAppPlatform/jolta 仓库中。
灵感源自 Node 的理念
Volta 在 Node 生态中很好地解决了这个问题：你在每个项目中固定一个工具版本，正确的版本会被自动使用，因为你的 node/npm 实际上是轻量级的垫片程序，会在调用时解析出正确的版本。无需目录切换钩子，也无需“我是否记得切换”的仪式性操作。
Jolta 将这一模式应用到了 JDK 上。
bash
cd my-service
jolta pin 21
java -version # → 自动使用 OpenJDK 21
jolta pin 21 会在项目中写入一个 .java-version 文件。从那时起，当你调用 java、javac、jar、jshell 等命令时，Jolta 的垫片程序会向上遍历目录树，找到最近的 .java-version 文件，并分发到正确的 JDK。每次调用的开销低于 5 毫秒。如果固定的 JDK 尚未安装，Jolta 会在首次使用时下载它。
解析机制如何工作
Jolta 按以下顺序解析要使用的版本：
显式设置的环境变量（如果已设置）
项目的 .java-version 文件（通过向上遍历目录树找到）
你的全局默认值（jolta default 21）
系统 JDK
在需要时，你也可以固定特定的发行版：
bash
jolta pin corretto@21
jolta default 21
为什么选择它（以及为什么不选择）
Jolta 试图做出以下不同之处：
自动化而非手动。核心要点是你无需在每个目录下运行切换命令——垫片程序会自动处理。
首日即兼容。它读取与 jenv 和 asdf 相同的 .java-version 文件，并识别 SDKMAN! 的 .sdkmanrc 文件。迁移过程基本上就是“安装 Jolta 并保留现有文件”。
单一无依赖的 Rust 二进制文件。一个静态二进制文件既包含命令行界面，也包含垫片程序。除了运行 jolta setup 外，无需在 Shell 中安装任何其他内容。
Windows 是一等公民，与 macOS（Apple Silicon + Intel）和 Linux（x86_64 + arm64）并列支持。
支持多种发行版：Temurin、Corretto、GraalVM、Oracle、Zulu。
现有主流工具可能仍然更适合你的情况：
SDKMAN! 管理的远不止 JDK（还包括 Gradle、Maven、Kotlin、Scala 等）。如果你希望用一个工具管理整个 Java 虚拟机工具链，这种广度是真实存在的优势。
mise / asdf 是跨多种语言的多面手，因此如果你还要管理 Node/Python/Ruby 版本，你可能更倾向于使用一个管理器来统筹一切。
那些项目成熟且经过实战检验；而 Jolta 尚处于早期阶段。
安装方法
macOS（Homebrew）：
bash
brew install OneAppPlatform/tap/jolta && jolta setup
Linux/macOS（一行命令）：
bash
curl -fsSL https://raw.githubusercontent.com/OneAppPlatform/jolta/main/install.sh | sh
Windows：从发布页面下载可执行文件，然后运行 jolta setup。
然后：
bash
jolta setup # 安装垫片程序 + Shell 配置
jolta catalog # 浏览可用版本
jolta pin 21 # 固定当前项目版本
jolta doctor # 诊断配置问题
动态源
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
