这种情况的核心矛盾在于jenv的版本管理逻辑和系统原生/usr/libexec/java_home工具的扫描机制不匹配，具体来说：

• jenv的system版本只是一个虚拟别名：它指向你系统中实际存在的JDK，但这个别名是jenv自己维护的，系统的java_home工具完全无法识别。
• 系统java_home只会扫描标准路径：它默认只查找/Library/Java/JavaVirtualMachines/目录下符合规范的JDK包，而jenv的版本信息都存在用户目录~/.jenv里，属于jenv的私有管理范围，系统工具看不到这些内容。
• 当你的JAVA_HOME被jenv设置为~/.jenv/versions/system时，这个路径对系统java_home来说不是一个有效的JDK根目录，所以它无法返回任何输出。

根据你的需求，有几个不同的处理方向：

1. 用jenv自带命令替代系统java_home #

既然你已经在用jenv管理JDK，完全可以用jenv的命令来获取当前生效的JDK路径，比系统工具更适配：

• 获取当前版本的JDK根目录：jenv prefix
• 获取当前java二进制文件的真实路径：jenv which java
• 查看所有已管理的JDK路径：可以直接看~/.jenv/versions/目录下的各个版本对应的软链接，比如ls -l ~/.jenv/versions/system就能看到它指向的真实JDK路径。

2. 让系统java_home识别到你的JDK #

如果一定要用系统java_home工具，需要确保你的JDK安装在它能扫描到的标准目录：

• 检查你的JDK是否在/Library/Java/JavaVirtualMachines/下：执行ls /Library/Java/JavaVirtualMachines/，如果看不到你的JDK，说明是安装在其他位置了。
• 把JDK移到标准目录或创建软链接：
  假设你的JDK真实路径是~/Downloads/openjdk-11.0.2.jdk，可以创建软链接让系统工具识别：

  sudo ln -s ~/Downloads/openjdk-11.0.2.jdk /Library/Java/JavaVirtualMachines/openjdk-11.0.2.jdk
  

  之后再运行/usr/libexec/java_home -V，应该就能看到对应的JDK条目了。

3. 临时绕过jenv测试系统java_home #

如果你想验证系统原生的java_home是否正常，可以临时禁用jenv的环境变量，比如在当前终端执行：

unset JAVA_HOME
PATH=$(echo $PATH | tr ':' '\n' | grep -v jenv | tr '\n' ':')

然后再运行/usr/libexec/java_home -V，如果这时候有输出，就说明确实是jenv的接管导致系统工具失效，这属于正常现象。

内容的提问来源于stack exchange，提问作者du-it