I understand the motivation behind your question. update-alternatives elegantly solves the problem of managing several installed versions of a program (for example Java) or different ports of a program (vim vs. elvis vs. vile) by making one of them the default one.

update-alternatives, found in many Linux distros, creates and manages a set of symlinks from /bin, /usr/bin (and the like) to /etc/alternatives, and from there to the location where the program is installed.

For example, in openSUSE java is symlinked to /etc/alternatives/java, which is symlinked to a "private" path where java resides:

/usr/bin/java -> /etc/alternatives/java
/etc/alternatives/java -> /usr/lib64/jvm/java-1.5.0-sun-1.5.0/jre/bin/java

Unfortunately, and although some think it would be necessary, at least for MacPorts, there is no such thing in OS X. I have personally solved the lack of update-alternatives with aliases in my .bashrc:

alias ls='/usr/local/bin/ls'

or simply changing $PATH:

PATH=/usr/local/bin:$PATH

If you can't solve it like this and are weighing the fact of porting it to OS X be aware that although update-alternatives' first incarnation was a Perl script, it was rewritten in C for Debian, and some other distros adopted it later (for instance openSUSE 12.1).

openSUSE 11.4 provides the Perl version as an RPM package. If you are looking for the C version, go for any recent Ubuntu or Debian release, or openSUSE 12.1 or later.

The command you are looking for is update-alternatives. So you should be running sudo update-alternatives --config java.

Oracle Java 7 and Apple Java 6 are completely different and they coexist on the same machine as they inhabit totally separate locations.

Java 7, if installed, lives in:

/Library/"Internet Plug-Ins"/JavaAppletPlugin.plugin/Contents/Home

Java 6, if installed, lives in:

/System/Library/Frameworks/JavaVM.framework/Versions/A/

(And the more traditional Java 6 JDK is at: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home)

When you type java, you're running /usr/bin/java, which is a symbolic link to Java 6. In fact, if you type ls -l /usr/bin | grep -i java you will see a bunch of symbolic links for the typical JDK/JRE executables.

So if you have installed Java 7, and that's what you want to use from the command line, you can change into its directory and run its specific binaries in bin. To avoid that, you can add its bin directory to your Bash search path, so its contents are invoked instead of the Java 6 symlinks in /usr/bin. To do this, alter /etc/paths to add the bin directory before the first line:

{ echo "/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/bin"; \
  cat /etc/paths; } | sudo tee /etc/paths > /dev/null

Then set the JAVA_HOME environment variable, so supporting software knows where to find Java 7:

{ echo -n "export JAVA_HOME=";
echo "/Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin/Contents/Home"; } \
| sudo tee -a /etc/bashrc > /dev/null

Now, in any new Terminal window, when you type java -version, you'll see java version "1.7.0_51". (And if you still want to be able to run the Java 6 binaries, you can call them with /usr/bin/java, /usr/bin/javac, etc.)

I was recommended to run update-alternatives --auto php or update-alternatives --config php which did not work for me. What worked however was this:

1. I manually deleted the faulty symlink under /etc/alternatives/php
2. I ran sudo update-alternatives --install /usr/bin/php php /usr/bin/php8.0 1 which, in contrast to the other commands, created a new and working symlink to the corresponding php version.

This restored normal functionality of update-alternatives and made me able to use php from cmd again.

Probably you have made a change in your system that prevent update-alternatives to work.

Expected behavior

As I know, in a typical installation, the java command is a symbolic link in /usr/bin/java. You must exclude the "real" java path from the $PATH variable. If your computer use a java command in a different directory, the update-alternatives will not work.

-- location of the java command
$ type -p java
/usr/bin/java

-- real location of the java command
$ readlink -f /usr/bin/java
/usr/lib/jvm/java-11-openjdk-amd64/bin/java 

If you get a different result for the type -p java command, you must check if the location of the java command is determined by some folder in the $PATH and remove that part.

NOTE: You may define the JAVA_HOME variable processing the /usr/bin/java symbolic link.

-- real location of the JAVA_PATH variable
$ dirname /usr/lib/jvm/java-11-openjdk-amd64/bin/java 
/usr/lib/jvm/java-11-openjdk-amd64/bin/

$ dirname /usr/lib/jvm/java-11-openjdk-amd64/bin/
/usr/lib/jvm/java-11-openjdk-amd64/

-- setting the JAVA_HOME variable
$ export JAVA_HOME=`type -p java|xargs readlink -f|xargs dirname|xargs dirname`

Assuming one has installed a JDK in /opt/java/jdk1.8.0_144 then:

1. Install the alternative for javac

   $ sudo update-alternatives --install /usr/bin/javac javac /opt/java/jdk1.8.0_144/bin/javac 1
   

2. Check / update the alternatives config:

   $ sudo update-alternatives --config javac
   

If there is only a single alternative for javac you will get a message saying so, otherwise select the option for the new JDK.

To check everything is setup correctly then:

$ which javac
/usr/bin/javac

$ ls -l /usr/bin/javac
lrwxrwxrwx 1 root root 23 Sep  4 17:10 /usr/bin/javac -> /etc/alternatives/javac

$ ls -l /etc/alternatives/javac
lrwxrwxrwx 1 root root 32 Sep  4 17:10 /etc/alternatives/javac -> /opt/java/jdk1.8.0_144/bin/javac

And finally

$ javac -version
javac 1.8.0_144

Repeat for java, keytool, jar, etc as needed.