It updates the links in /etc/alternatives to point to the program for this purpose. There's lots of examples, like x-www-browser, editor, etc. that will link to the browser or editor of your preference. Some scripts or system tools may want you to edit a file manually (e.g. configuration conflict in dpkg) and they'll look into the alternatives to give you the editor of choice. For java, this is the Java runtime environment - Oracle's, OpenJRE, etc.

The links in /etc/alternatives are just symbolic links. You can see them using for example

ls -l /etc/alternatives

Moreover, the regular /usr/bin binaries are also symlinks. E.g.:

ls -l /usr/bin/java
  lrwxrwxrwx 1 root root 22 Aug 14 10:33 /usr/bin/java -> /etc/alternatives/java
ls -l /etc/alternatives/java
  lrwxrwxrwx 1 root root 46 Aug 14 10:33 /etc/alternatives/java -> /usr/lib/jvm/java-6-openjdk-amd64/jre/bin/java

So, no PATH has to be modified. It just uses symbolic links.

Basically it says to your machine to use this alternative of Jave JDK instead of the default one, which, in Linux systems, is OpenJDK.

A brief extract from the man page is better than any answer I could write:

update-alternatives creates, removes, maintains and displays information about the symbolic links comprising the Debian alternatives system.

It is possible for several programs fulfilling the same or similar functions to be installed on a single system at the same time. For example, many systems have several text editors installed at once. This gives choice to the users of a system, allowing each to use a different editor, if desired, but makes it difficult for a program to make a good choice for an editor to invoke if the user has not specified a particular preference.

Debian's alternatives system aims to solve this problem. A generic name in the filesystem is shared by all files providing interchangeable functionality. The alternatives system and the system administrator together determine which actual file is referenced by this generic name. For example, if the text editors ed(1) and nvi(1) are both installed on the system, the alternatives system will cause the generic name /usr/bin/editor to refer to /usr/bin/nvi by default. The system administrator can override this and cause it to refer to /usr/bin/ed instead, and the alternatives system will not alter this setting until explicitly requested to do so.

With --install you specified a link, "/usr/bin/java" a name "java" and a path "/usr/lib/java/JDK...." and you add a group of alternatives to the system. link is the generic name for the master link, name is the name of its symlink in the alternatives directory, and path is the alternative being introduced for the master link.

I hope to be clear enough, Here there is a post regarding java alternatives.

For the complete usage list I suggest to look at the same manual page, typing man update-alternatives on your OS shell;

To answer your first question I'd like to hint you to --query:

   --query name
          Display information about the link group like --display does, but in a machine parseable way (see section QUERY FORMAT below).

Armed with this you will get the link source, e.g. in my case for java:

usr@srv % update-alternatives --query java
Name: java
Link: /usr/bin/java
[...]

So, you see my chain goes like /usr/bin/java -> /etc/alternatives/java -> ....

Unfortunately, I don't have an answer to your second question. I've been searching for a solution for this some time ago, but it seems that there is no simple workaround, yet. What you could do is writing some hack to parse the output of the --query call, maybe like this:

update-alternatives --query java | /bin/grep Link | cut -f 2 -d " "

which you could then use as input for the --install call. But since this is quite messy in my opinion I won't recommend it. Instead you might want to have a look at galternatives, a front-end to the alternatives system. Even if I don't like to use graphical stuff for such basic jobs it is quite convenient and I ended up using this tool instead of the command line tools.

EDIT

I've been curious how update-alternatives knows what's the command symlink and took a short look into the sources. Of course the alternatives system has to store the config for each group and it turns out that it's called administrative directory and written on the man page ;-)

You'll find this information in /var/lib/dpkg/alternatives (by default). The second line in each of these files defines the master link you're looking for. You may extract it like this:

usr@srv $ sed -ne 2p /var/lib/dpkg/alternatives/java
/usr/bin/java

However, this is just a workaround for those having an older version of update-alternatives.

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.