1. 为何你的开发机里总是一堆JDK版本在打架
先说个场景,我相信绝大多数Java开发者都经历过。你手上同时维护着两三个项目,老项目跑在JDK 8上,Spring Boot 2.x那套,动不得;新项目要用Spring Boot 3,逼着你上JDK 17;偶尔还有个老旧的Gradle构建脚本,连--release参数都不认识,JDK 8和JDK 17它都嫌不对。你怎么办?装两个JDK,然后每次切换项目之前,手动去系统环境变量里改JAVA_HOME,改完还得重新开终端,敲一句java -version验一下,确认没改错。
这种操作一次两次还好,一个月下来你就烦了。尤其是有一次我为了切JDK版本,手滑把Path变量里其他内容也改了,导致终端里连mvn命令都找不到了,整整排查了半个多小时,最后发现是环境变量里一个分号被误删。那一刻我就下定决心,必须找一个正经的多版本管理工具来干这件事。
这就是我这次要详细说的 JDK多版本管理工具jvms。它的定位非常纯粹:让你在同一个操作系统上安装多个JDK版本,并且随时一键切换,彻底告别手动修改环境变量的时代。除了jvms,生态里也有SDKMAN这类老牌工具,但jvms在Windows平台上有自己的优势,后面我会专门做对比。如果你手头正好为"同事要我JDK降级到17""项目构建找不到JDK""IDEA里配的JDK和终端对不上"这类问题焦头烂额,这篇文章可以帮你把整条链路打通。
适合读这篇文章的人,我总结了一下:刚入门Java、第一次被环境变量折磨的新手;在本机装了五六个JDK但从来没搞明白怎么管理的资深开发;还有需要在多个项目之间频繁切换JDK版本的维护型选手。前面两类读者,今天这篇文章应该能让你少走很多弯路。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. jvms到底是什么,和手动改环境变量差在哪
2.1 核心原理:一个代理层搞定所有版本切换
jvms的工作机制,其实一句话就能说清楚:它在你系统里维护了一个"当前JDK"的指向,你执行jvms use命令的时候,它会把系统的JAVA_HOME和相关路径重新指向你选中的那个JDK目录,然后所有依赖JAVA_HOME的工具(Maven、Gradle、IDEA里的终端等)就都跟着走了。
这个思路和Node.js的nvm、Python的pyenv是同一个套路。你可以理解成:你的电脑里安装了很多个JDK实体,它们安安静静地躺在各自的目录里,平时互不打扰;jvms是那个站在前台的管理员,你喊一声"切换到JDK 17",它立刻把门口的招牌(环境变量)换成JDK 17的地址。
和手动管理相比,差别是结构性。手动管理时,JAVA_HOME写死在系统属性里,你要修改就得打开系统设置,一层一层点进去,改完还要处理Path里可能存在的其他JDK残留路径。jvms管理时,JAVA_HOME指向的是一个由jvms动态维护的位置,你完全不需要关心真实JDK装在哪里,只用告诉jvms你想用哪个版本,剩下的事情它处理。
2.2 jvms、SDKMAN、手动管理三者的横向对比
很多人第一反应是,我用SDKMAN不就行了?确实,SDKMAN在macOS和Linux上非常好用,我周围不少同事都在用。但SDKMAN本身是为Unix-like系统设计的,在Windows上需要借助Git Bash或WSL才能跑,体验还是隔了一层。jvms的设计目标从一开始就覆盖Windows、macOS和Linux,对Windows用户友好得多。
| 对比维度 | jvms | SDKMAN | 手动管理 |
|---|---|---|---|
| Windows原生支持 | 好,直接命令行使用 | 需要Git Bash/WSL | 原生但繁琐 |
| 版本切换速度 | 快,秒级 | 快,秒级 | 慢,改环境变量+重开终端 |
| 多版本并行安装 | 支持 | 支持 | 自己下载解压也行 |
| 版本自动下载 | 支持,内置下载源 | 支持 | 自己上官网找 |
| 学习成本 | 低,命令少 | 低 | 无但易出错 |
| 对现有项目无侵入 | 是 | 是 | 是 |
这里多说一句,手动管理并不完全一无是处。如果你一年到头只需要一个JDK版本,装好之后基本不动,那手动装一次也无妨。但只要你有一个"JDK降级到17"或者"临时要用JDK 8跑一个老项目"的需求,手动管理的成本瞬间就上来了。jvms这类工具的价值,正是在这种频率不高但每次都很折腾的场景里体现得最充分。
3. jvms从零安装到初始化,Windows和macOS两条路都走一遍
3.1 Windows下的安装步骤:比想象中简单
先说Windows,这也是jvms覆盖最用力的平台。安装方式大致分两种:用包管理器,或者直接下载可执行文件。
如果你电脑里装
