本文发布于 2025-05-12， 最后更新于 97 天前，其中的信息可能已经有所发展或是发生改变。
文章摘要
🚨 事故现场：当SDKMAN遇上java_home 我使用 sdkman 来管理多个 java 版本，每次在终端输入 java -version 时都岁月静好，直到今天使用 gradle 编译项目时，却突然举着告示牌抗议：「找不到JDK，罢工了！」 重新查看日志，原来是 macos 自带的 /usr/libexec/java_home 程序不识别 sdkman 安装的 java ，所以需要我们通…
🚨 事故现场：当SDKMAN遇上java_home 我使用 sdkman 来管理多个 java 版本，每次在终端输入 java -version 时都岁月静好，直到今天使用 gradle 编译项目时，却突然举着告示牌抗议：「找不到JDK，罢工了！」 重新查看日志，原来是 macos 自带的 /usr/libexec/java_home 程序不识别 sdkman 安装的 java ，所以需要我们通过一些小 trick 来骗过 macos ，使得 sdkman 安装的 java 也能被系统识别到。 为了增强文章阅读的趣味性，这篇文章我试着使用 ai 来润色和生成文本，今后我的博客也会更多的借助 aigc 的力量，来辅助我讲清楚一些容易被我遗漏的知识细节，让后来的初学者也能更容易理解我的解决思路，并复现我的技术解决方案。 两大阵营的冲突根源 🍎 苹果原住民JDK 住在 /Library/Java/JavaVirtualMachines 高档小区，每户都有： 🏠 Contents/Home （真实住宅） 📄 Info.plist （房产证明） 🚀 SDKMAN太空移民 蜗居在 ~/.sdkman 的集装箱公寓，只有： 🧳 精简版JDK文件 ❌ 没有房产证和门牌号 🔧 偷天换日三步走 第1步：伪造身份档案 # 在苹果JDK小区买个虚拟房产 sudo mkdir -p /Library/Java/JavaVirtualMachines/sdkman-current/Contents 第2步：制造时空隧道 # 创建跨次元传送门（ YOUR_USERNAME 替换为你的用户名） sudo ln -s /Users/ YOUR_USERNAME /.sdkman/candidates/java/current \ /Library/Java/JavaVirtualMachines/sdkman-current/Contents/Home 第3步：办理假身份证 !-- 伪造Info.plist文件 -- cat EOF | sudo tee /Library/Java/JavaVirtualMachines/sdkman-current/Contents/Info.plist ?xml version="1.0" encoding="UTF-8"? !DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd" plist version="1.0" dict key CFBundleIdentifier /key string sdkman.current /string key CFBundleName /key string SDKMAN Current JDK /string key JavaVM /key dict key JVMPlatformVersion /key string 9999 /string key JVMVendor /key string Homebrew /string key JVMVersion /key string 9999 /string /dict /dict /plist EOF 🧪 验收测试 # 查看当前JDK路径 /usr/libexec/java_home 应该输出： /Library/Java/JavaVirtualMachines/sdkman-current/Contents/Home 查看所有已识别JDK /usr/libexec/java_home -V 输出示例： Matching Java Virtual Machines (1): 9999 (arm64) "Homebrew" - "SDKMAN Current JDK" /Library/Java/JavaVirtualMachines/sdkman-current/Contents/Home /Library/Java/JavaVirtualMachines/sdkman-current/Contents/Home 💡 原理黑匣子 系统行为 我们的伪装术 扫描标准JDK目录 创建虚拟目录结构 检查Info.plist合法性 伪造包含必要字段的配置文件 验证JVM实际存在 符号链接指向真实SDKMAN路径 版本号9999的阴谋 ：通过设置超高版本号，确保系统总是优先选择我们的「超级JDK」 ⚠️ 注意事项 如果升级macOS系统，可能需要重新配置 💥 常见翻车现场急救包 症状1：操作后 java_home 依然装瞎 三连诊断术 ls -l /Library/Java/JavaVirtualMachines/sdkman-current/Contents/Home # 检查传送门是否畅通 plutil -lint Info.plist # 验证身份证是否伪造成功 java -version # 确认SDKMAN当前JDK是否正常 🌟 结语 🚀 神操作总结（一张图看懂） # 总操作流程图 +------------------+ +------------------+ +------------------+ | 伪造JDK别墅 | | 创建传送门 | | 办理9999号身份证 | | mkdir -p |------ | ln -s |------ | Info.plist | +------------------+ +------------------+ +------------------+ 🌈 哲学时间 为什么java_home这么固执？ 就像机场安检员坚持要检查登机牌， java_home 的设计哲学是： 只相信官方认证的JDK（防止有人携带危险品） 严格检查目录结构（登机口必须符合IATA标准） 版本号就是VIP等级（所以我们的9999是超级黑卡） 🎉 最终效果演示 # 在XCode中优雅调用（Build Phase脚本示例） export JAVA_HOME=$(/usr/libexec/java_home) ./gradlew build --stacktrace # 现在可以愉快甩锅给Android Studio了 📚 引用 xcode - How to make /usr/libexec/java_home find JDK installed using SDKMAN on MacOS? - Stack Overflow🚨 事故现场：当SDKMAN遇上java_home
我使用 sdkman 来管理多个 java 版本，每次在终端输入java -version时都岁月静好，直到今天使用 gradle 编译项目时，却突然举着告示牌抗议：「找不到JDK，罢工了！」
重新查看日志，原来是 macos 自带的 /usr/libexec/java_home 程序不识别 sdkman 安装的 java，所以需要我们通过一些小 trick 来骗过 macos，使得 sdkman 安装的 java 也能被系统识别到。
为了增强文章阅读的趣味性，这篇文章我试着使用 ai 来润色和生成文本，今后我的博客也会更多的借助 aigc 的力量，来辅助我讲清楚一些容易被我遗漏的知识细节，让后来的初学者也能更容易理解我的解决思路，并复现我的技术解决方案。
两大阵营的冲突根源
- 🍎 苹果原住民JDK 住在
/Library/Java/JavaVirtualMachines高档小区，每户都有：- 🏠
Contents/Home（真实住宅） - 📄
Info.plist（房产证明）
- 🏠
- 🚀 SDKMAN太空移民 蜗居在
~/.sdkman的集装箱公寓，只有：- 🧳 精简版JDK文件
- ❌ 没有房产证和门牌号
🔧 偷天换日三步走
第1步：伪造身份档案
text
# 在苹果JDK小区买个虚拟房产
sudo mkdir -p /Library/Java/JavaVirtualMachines/sdkman-current/Contents
第2步：制造时空隧道
text
# 创建跨次元传送门（<YOUR_USERNAME>替换为你的用户名）
sudo ln -s /Users/<YOUR_USERNAME>/.sdkman/candidates/java/current
/Library/Java/JavaVirtualMachines/sdkman-current/Contents/Home
第3步：办理假身份证
<!-- 伪造Info.plist文件 -->
django (Auto identified)
cat <<EOF | sudo tee /Library/Java/JavaVirtualMachines/sdkman-current/Contents/Info.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>CFBundleIdentifier</key>
<string>sdkman.current</string>
<key>CFBundleName</key>
<string>SDKMAN Current JDK</string>
<key>JavaVM</key>
<dict>
<key>JVMPlatformVersion</key>
<string>9999</string>
<key>JVMVendor</key>
<string>Homebrew</string>
<key>JVMVersion</key>
<string>9999</string>
</dict>
</dict>
</plist>
EOF
🧪 验收测试
text
# 查看当前JDK路径
/usr/libexec/java_home
应该输出：
text
/Library/Java/JavaVirtualMachines/sdkman-current/Contents/Home
查看所有已识别JDK
text
/usr/libexec/java_home -V
输出示例：
dart (Auto identified)
Matching Java Virtual Machines (1):
9999 (arm64) "Homebrew" - "SDKMAN Current JDK" /Library/Java/JavaVirtualMachines/sdkman-current/Contents/Home
/Library/Java/JavaVirtualMachines/sdkman-current/Contents/Home
💡 原理黑匣子
| 系统行为 | 我们的伪装术 |
|---|---|
| 扫描标准JDK目录 | 创建虚拟目录结构 |
| 检查Info.plist合法性 | 伪造包含必要字段的配置文件 |
| 验证JVM实际存在 | 符号链接指向真实SDKMAN路径 |
版本号9999的阴谋：通过设置超高版本号，确保系统总是优先选择我们的「超级JDK」
⚠️ 注意事项
- 如果升级macOS系统，可能需要重新配置
💥 常见翻车现场急救包
症状1：操作后java_home依然装瞎
三连诊断术
text
ls -l /Library/Java/JavaVirtualMachines/sdkman-current/Contents/Home # 检查传送门是否畅通
text
plutil -lint Info.plist # 验证身份证是否伪造成功
text
java -version # 确认SDKMAN当前JDK是否正常
🌟 结语
🚀 神操作总结（一张图看懂）
gherkin (Auto identified)
# 总操作流程图
+------------------+ +------------------+ +------------------+
| 伪造JDK别墅 | | 创建传送门 | | 办理9999号身份证 |
| mkdir -p |------>| ln -s |------>| Info.plist |
+------------------+ +------------------+ +------------------+
🌈 哲学时间
为什么java_home这么固执？
就像机场安检员坚持要检查登机牌，java_home的设计哲学是：
- 只相信官方认证的JDK（防止有人携带危险品）
- 严格检查目录结构（登机口必须符合IATA标准）
- 版本号就是VIP等级（所以我们的9999是超级黑卡）
🎉 最终效果演示
text
# 在XCode中优雅调用（Build Phase脚本示例）
export JAVA_HOME=$(/usr/libexec/java_home)
./gradlew build --stacktrace # 现在可以愉快甩锅给Android Studio了
📚 引用
本文采用 CC BY-NC-SA 4.0 协议进行授权，如无注明均为原创，转载请注明出处。
标题：让SDKMAN的JDK在macOS上「合法上岗」的全套骚操作作者：九仞之行链接：http://dev.styunlen.cn/archives/post-1716.html
还没有评论呢 ~ 快来抢沙发吧 🛋️