Re: CLASSPATH and Jikes
I recognize this discussion from some discussions some time ago.
Then we discussed that every package that provides java classes should
define its CLASSPATH in some way. I'd really like to see this in action.
There are suggestions in http://bugs.debian.org/103420
I'll include it here for clarification:
From: Ben Burton <firstname.lastname@example.org>
Subject: Proposed addition to java-common
Date: Tue, 3 Jul 2001 21:34:49 -0500
X-Mailer: KMail [version 1.2.9]
Hi. Policy states that Java programs must run without specific environment
variables, which can be some hassle when writing a program that works with
several JVMs. Different JVMs use different bootstrap classes - which
sometimes need to be passed on the command line (eg. kaffe) - and often even
have different binaries for execution (/usr/bin/java, /usr/bin/kaffe, etc).
I have written a script that will try to guess which command to use for the
java runtime and which bootstrap classes need to be passed on the command
line. It does this by trying some standards commands (java, kaffe, etc).
When it finds one that works, it runs it to get version information; from
that it determines which JVM is being used and from there works out what
bootstrap classes to pass. All decisions it makes can be manually overridden
by setting the appropriate environment variables (although the entire point
is that you don't *need* to set such variables and everything should still
I've only tested blackdown and kaffe (japhar won't even run on my system) but
it should be relatively straightforward to add other JVMs to the recognition
My proposal is that this script be included in java-common, since in theory
it could be used to create a runtime script for almost every java program
that is packaged. I currently have it on my system as /usr/bin/find_java.
If this is accepted for java-common, I will happily write a full man page to
go with it. There is also a /usr/bin/find_javac in the works with the
obvious alternate goal.
The script /usr/bin/find_java is included below.
# find_java - Script utilities for guessing Java runtime and classpath
# Copyright (c) 2001 Ben Burton <email@example.com>
# Written for Debian GNU/Linux
# Released under LGPL
# Usage: find_java [ --eval | --print ]
# Writes a shell command to standard output that can be slurped into
# another script using eval. The output will look like:
# JVM="funky" ;
# JAVA="chickens" ;
# The following line in your own script will thus call this script
# and set the corresponding variables in your script:
# eval `find_java --eval`
# Writes its guesses to standard output in human-readable form.
# $JAVA will be set to the command that starts the Java interpreter
# (such as /usr/bin/java).
# $JVM will be set to a token describing which particular Java virtual machine
# is called by $JAVA. Tokens that are currently returned are listed
# $BOOTSTRAP_CLASSES will be set to the part of the classpath
# containing the core Java classes. This will be left empty if $JAVA
# does not require this part of the classpath to be specified.
# If any of these variables are already set in the environment, the
# values from the environment will be used.
# This script is not guaranteed to work; it merely makes educated
# guesses. It should work for all the JVMs distributed with Debian.
# Exit status: 0 on success, 1 if no intelligent guesses could be made.
# JVM tokens:
# blackdown: Blackdown port of the Sun Java runtime
# kaffe: Kaffe virtual machine from Transvirtual
# unknown: Some other JVM
case "$1" in
echo "Usage: $0 [ --eval | --print ]"
echo "See comments at the beginning of this script for further details."
# Determine the java runtime command.
if [ -z "$JAVA" ]; then
# Check for common JVMs.
if which java >& /dev/null; then
elif which kaffe >& /dev/null; then
echo "Cannot locate a Java virtual machine."
echo "Set the environment variable \$JAVA to the command that starts"
echo "your Java interpreter (such as /usr/bin/java) and try again."
# Determine whose JVM we are using.
if ! version=`"$JAVA" -version 2>&1`; then
case "$version" in
# Search for a string not included in $JAVA so we don't accidentally
# catch output such as "kaffe: Command not found" and the like.
# No idea.
# Determine the bootstrap classes.
if [ -z "$BOOTSTRAP_CLASSES" ]; then
case "$JVM" in
if [ -e /usr/share/kaffe/Klasses.jar ]; then
BOOTSTRAP_CLASSES=`echo $kaffejars | tr ' ' ':'`
echo "The core Kaffe classes could not be found."
echo "Set the environment variable \$BOOTSTRAP_CLASSES to a"
echo "colon-separated list of jars containing the core Kaffe"
echo "classes (such as /usr/share/kaffe/Klasses.jar) and try again."
# Don't need to specify bootstrap classes.
# Let's hope we have a JVM that automagically knows where its
# bootstrap classes are.
case "$1" in
echo "JVM=\"$JVM\" ;"
echo "JAVA=\"$JAVA\" ;"
echo "JVM: $JVM"
echo "Runtime: $JAVA"
echo "Bootstrap classes: $BOOTSTRAP_CLASSES"
After this proposal there was a lot of discussion. I'l love
to see similar functionality for this. Also there should be
a wrapper for java and javac that takes this information and
uses the proper jvm or compiler.
On Tue, Apr 02, 2002 at 03:34:51PM -0500, Andrew Pimlott wrote:
> On Tue, Apr 02, 2002 at 08:43:55PM +0200, Robert Bihlmeyer wrote:
> > firstname.lastname@example.org writes:
> > > I also think the jikes-kaffe, etc proposals are silly: You should
> > > be able to achieve the same with a simple "jikes -bootclasspath
> > > /wherever/kaffe/puts/Klasses.jar".
> > Oh, you don't seem to know the path from the top of your head!
> Well, I would put it once in my Makefile and forget about it. :-)
> > Me
> > neither. That's the point of jikes-kaffe: relieving you from having to
> > remember the obscure bootclasses path(s).
> > Of course this could be combined sensibly with your idea: If everybody
> > providing a JRE would provide /usr/share/<mumble>/<pkgname>.classpath
> > we could enhance jikes (or a simple shell wrapper, not necessary named
> > "jikes") so that "-jre foo" would take the base classes from package
> > foo.
> Absolutely, this idea is nicer. It just requires a little more
> infrastructure, and I was trying to give the simplest version of the
> concept (which is that the ability to choose core classes should be
> decentralized). It can be seen as one step towards the full Java
> registry idea.
I like this idea. The question is what format should it have and
what should it contain? Last time there was a lot of proposals
from debian/control-like format to xml. I'd like something simple
that you can extract things from using sed, grep and other
simple command line tools. It make things easier.
> BTW, I remembered that jikes knows how to read command-line
> arguments from a file, so "jikes -jre $foo" just becomes "jikes
> -bootclasspath @/usr/share/java/$foo/bootclasspath", or similar.
> To UNSUBSCRIBE, email to email@example.com
> with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org
--------------------- Ola Lundqvist ---------------------------
/ email@example.com Björnkärrsgatan 5 A.11 \
| firstname.lastname@example.org 584 36 LINKÖPING |
| +46 (0)13-17 69 83 +46 (0)70-332 1551 |
| http://www.opal.dhs.org UIN/icq: 4912500 |
\ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 /
To UNSUBSCRIBE, email to email@example.com
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org