本文发布于292天前，最后更新于 292 天前，其中的信息可能已经有所发展或是发生改变。

🚨 事故现场：当SDKMAN遇上java_home

我使用 sdkman 来管理多个 java 版本，每次在终端输入java -version时都岁月静好，直到今天使用 gradle 编译项目时，却突然举着告示牌抗议：「找不到JDK，罢工了！」

重新查看日志，原来是 macos 自带的 /usr/libexec/java_home 程序不识别 sdkman 安装的 java，所以需要我们通过一些小 trick 来骗过 macos，使得 sdkman 安装的 java 也能被系统识别到。

为了增强文章阅读的趣味性，这篇文章我试着使用 ai 来润色和生成文本，今后我的博客也会更多的借助 aigc 的力量，来辅助我讲清楚一些容易被我遗漏的知识细节，让后来的初学者也能更容易理解我的解决思路，并复现我的技术解决方案。

两大阵营的冲突根源

  1. 🍎 苹果原住民JDK 住在/Library/Java/JavaVirtualMachines高档小区，每户都有：
    • 🏠 Contents/Home（真实住宅）
    • 📄 Info.plist（房产证明）
  2. 🚀 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」

⚠️ 注意事项

  1. 如果升级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的设计哲学是：

  1. 只相信官方认证的JDK（防止有人携带危险品）
  2. 严格检查目录结构（登机口必须符合IATA标准）
  3. 版本号就是VIP等级（所以我们的9999是超级黑卡）

🎉 最终效果演示

# 在XCode中优雅调用（Build Phase脚本示例）
export JAVA_HOME=$(/usr/libexec/java_home)
./gradlew build --stacktrace # 现在可以愉快甩锅给Android Studio了

📚 引用