[25984] in Athena Bugs
Re: linux 9.3.11: /usr/bin/java
daemon@ATHENA.MIT.EDU (Jacob Morzinski)
Tue Aug 24 17:22:51 2004
To: bugs@mit.edu
From: Jacob Morzinski <jmorzins@mit.edu>
Date: 24 Aug 2004 17:22:44 -0400
In-Reply-To: <bugs:25940@unknown-discuss-server>
Message-ID: <w6m8yc4xmcb.fsf@opus.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Errors-To: bugs-bounces@mit.edu
<daemon@ATHENA.MIT.EDU> (Jacob Morzinski) writes:
> What's wrong:
> Typing "java" at the prompt runs a shell script that prints
> text to the terminal and takes no other action.
I tried to see if I could learn more about the way RedHat
machines expect to handle Java. I didn't find a satisfying
answer, but can share what I found.
The current wrapper script for /usr/bin/java is ultimately
located in /usr/share/java/libgcj-java-placeholder.sh
and is reached through a chain of symlinks. The chain of
symlinks is managed by what looks like a custom RedHat hack:
the alternatives(8) system.
The manpage describes a little of how alternatives(8) works, and
I found a web page that provides an example of how to switch from
one java config to another:
http://www.reliablepenguin.com/blogs/index.php?cat=15
Unfortunately, using the alternatives system requires that
we have actual files to point the /usr/bin/java and
/usr/bin/javac symlinks at. The cluster machines have a local
version of java, but do not have a local version of javac.
It looks like that if we wanted to play nice with RedHat and use
alternatives(8), it would be necessary to write wrapper scripts
for javac, (and possibly also for jar, java, rmic, and others),
so that we had our own file to point /usr/bin/javac at.
Another possible reaction would be to remove the "libgcj" package.
Looking at the output of "rpm --scripts -q libgcj", libgcj is the
package that installs the /usr/bin/java* symlinks in its
postinstall scripts, and will uninstall the /usr/bin/java*
symlinks in its postuninstall script.
That's all I learned.
-Jacob
