Note that Big Sur breaks the previous behaviour of the JAVA_HOME environment variable to pick the Java version used to run the command-line tools. If this matters to you, consider filing an bug report.

In my case if JAVA\_HOME is not set, then the java_home command will not output anything at all. Even the -V option or --xml option that lists what is available doesn't work unless JAVA\_HOME is already set to a valid JDK folder.

I should correct my last comment. If JAVA\_HOME is completely unset, then it is possible to get useful output from /usr/lib/java\_home. However, if it is set to a value that is not a valid path to one of the installed JDKs, then the java\_home command will not function at all. This includes if JAVA\_HOME is set to an empty string (which is why I was a bit confused before). If JAVA_HOME is set to an empty string or an invalid path, /usr/libexec/java\_home is useless. This is a significant change in behaviour from prior versions of macOS.

So is there a solution to this or not? It's absurd that GUI programs on macOS can't run command line tools that aren't pre-installed. For the record, the application I'm running DOES have a configuration to point it to the path of the tool I want to run. The problem is that when it runs this tool, the path is inherited from the GUI app and so later when the tool that is directly invoked wants to run other command line tools it fails. The tool works fine when invoked from a regular command line, so there is no motivation for the tool developers to do anything about this. The PATH is the standard way to make command line tools accessible and it works for everything else. The decision to disallow configuring the PATH for GUI apps causes a lot of headaches.