/usr/libexec/java_home -v<version> 找到正确的 JDK 版本，但仅在第一次更新</version>

Question

I have just got a mac mini with M1 processor, and I find this behaviour very weird. Basically, when running /usr/libexec/java_home -v ## I can see that only the first time the JDK path is found and replaced. If I run it a second time even with a -V flag, I see it finds the right JDK path, yet it never replaces the old one, in fact making the whole thing stale.

Any idea why? This is an example taken from my terminal.

lda@Lucios-Mac-mini ~ % /usr/libexec/java_home -V   
Matching Java Virtual Machines (3):
    15 (x86_64) "AdoptOpenJDK" - "AdoptOpenJDK 15" /Library/Java/JavaVirtualMachines/adoptopenjdk-15.jdk/Contents/Home
    13.0.5.1 (arm64) "Azul Systems, Inc." - "Zulu 13.35.1017" /Library/Java/JavaVirtualMachines/zulu-13.jdk/Contents/Home
    11.0.9.1 (arm64) "Azul Systems, Inc." - "Zulu 11.43.1015" /Library/Java/JavaVirtualMachines/zulu-11.jdk/Contents/Home
/Library/Java/JavaVirtualMachines/adoptopenjdk-15.jdk/Contents/Home

lda@Lucios-Mac-mini ~ % java --version              
openjdk 15 2020-09-15
OpenJDK Runtime Environment AdoptOpenJDK (build 15+36)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 15+36, mixed mode, sharing)

lda@Lucios-Mac-mini ~ % export JAVA_HOME=$(/usr/libexec/java_home -v11) 

lda@Lucios-Mac-mini ~ % java --version                                 
openjdk 11.0.9.1 2020-11-04 LTS
OpenJDK Runtime Environment Zulu11.43+1015-CA (build 11.0.9.1+1-LTS)
OpenJDK 64-Bit Server VM Zulu11.43+1015-CA (build 11.0.9.1+1-LTS, mixed mode)

lda@Lucios-Mac-mini ~ % export JAVA_HOME=$(/usr/libexec/java_home -v15)

lda@Lucios-Mac-mini ~ % java --version                                 
openjdk 11.0.9.1 2020-11-04 LTS
OpenJDK Runtime Environment Zulu11.43+1015-CA (build 11.0.9.1+1-LTS)
OpenJDK 64-Bit Server VM Zulu11.43+1015-CA (build 11.0.9.1+1-LTS, mixed mode)

lda@Lucios-Mac-mini ~ % export JAVA_HOME=$(/usr/libexec/java_home -v13)

lda@Lucios-Mac-mini ~ % java --version                                 
openjdk 11.0.9.1 2020-11-04 LTS
OpenJDK Runtime Environment Zulu11.43+1015-CA (build 11.0.9.1+1-LTS)
OpenJDK 64-Bit Server VM Zulu11.43+1015-CA (build 11.0.9.1+1-LTS, mixed mode)

Answer 1

I've got an M1 mac, and for me the error is definitely with java_home always returning the same value, not with an inability to reassign shell variables (ie JAVA_HOME).

I've got an M1 mac and I have installed azul jvms:

$ /usr/libexec/java_home -V
    Matching Java Virtual Machines (3):
    11.0.9.1 (arm64) "Azul Systems, Inc." - "Zulu 11.43.1021" /Library/Java/JavaVirtualMachines/zulu-11.jdk/Contents/Home
    9.0.4.0.11 (x86_64) "Oracle Corporation" - "Java" /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home
    1.8.0_275 (arm64) "Azul Systems, Inc." - "Zulu 8.50.0.1017" /Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home

and I get this always zulu-11:

$ /usr/libexec/java_home -v 1.8
/Library/Java/JavaVirtualMachines/zulu-11.jdk/Contents/Home

and still get zulu-11 for:

$ /usr/libexec/java_home -v9
/Library/Java/JavaVirtualMachines/zulu-11.jdk/Contents/Home

I thought I could work-around by filtering stdout from just calling with the '-V' argument, but the results of that call go to stderr. So here's a version that works to select JDK 1.8 (specify the version just after 'awk'):

$ export JAVA_HOME=`/usr/libexec/java_home -V  2>&1 >/dev/null | awk '/1.8/ {print $NF}'`

With thanks to first answers here: How can I pipe stderr, and not stdout? and here: Printing the last column of a line in a file

Having said all of the above, it all seems to go a bit wobbly, when using zsh (perhaps I'm changing too many things at once), as the output is slightly different, and it includes the current setting. I can get this to work:

JAVA_HOME=`/usr/libexec/java_home -V 2> /dev/fd/1 | awk '/^\ \ \ \ 1.8/ {print $NF}'`; java -version"

but all bets are off, if JAVA_HOME becomes unset, or wrong, as java_home will not print out the list in that situation. Probably until java_home is fixed, I will stick with simple aliases in my.bash_profile/.zshrc of:

alias j8="export JAVA_HOME=/Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home; java -version"
alias j11="export JAVA_HOME=/Library/Java/JavaVirtualMachines/zulu-11.jdk/Contents/Home; java -version"

rather than:

alias j11="export JAVA_HOME=`/usr/libexec/java_home -V 2> /dev/fd/1 | awk '/^\ \ \ \ 11/ {print $NF}'`; java -version"
alias j8="export JAVA_HOME=`/usr/libexec/java_home -V 2> /dev/fd/1 | awk '/^\ \ \ \ 1.8/ {print $NF}'`; java -version"

which will work again, when java_home works, but TBH, I'm changing the jdk rarely enough for it to be a problem, and when I do... because azul go with a shorter directory name, which does not include patch version nos... I expect it will be OK. I'll cross that bridge, when I come to it.