Re: CLASSPATH and Jikes
On Fri, Mar 29, 2002 at 09:59:28PM -0600, Adam Majer wrote:
> At this moment I am the maintainer for Jikes. The one thing that I
> do not like about the package is that it does not work out of the
> box without some intervention from the user. That is, CLASSPATH
> needs to be defined.
> The trouble is that I don't think it is up to me to decide which
> java classes jikes should use.
If there will be a default classpath for jikes, it seems to me
natural that it should be the same classpath that the default java
VM uses. Since the default VM is controlled by alternatives, I
think that the classpath should be determined as a slave alternative
of the VM. This would make the compilation and runtime environments
So, kaffe would add an alternative of
/wherever/kaffe/puts/Klasses.jar for (eg)
/usr/share/java/bootclasses.jar . And jikes would take its
bootclasspath (by default) from /usr/shar/java/bootclasses.jar.
Using bootclasspath instead of classpath gives users the ability to
add their own libraries to the classpath without worrying about the
The one hitch is that I don't see it written anywhere that the
bootclasspath must be a single JAR. It might be necessary instead
for kaffe to supply a file /usr/share/kaffe/bootclasspath containing
"/wherever/kaffe/puts/Klasses.jar", as an alternative for
/usr/share/java/bootclasspath. Then, jikes defaults to "jikes
-bootclasspath `cat /usr/share/java/bootclasspath`". Slightly
annoying, but I believe it covers all the bases.
I think this is preferable to hard-coding information about the
different VM's in the jikes package. Granted, it will take some
time before the VM's provide these alternatives; but the pain is not
that great, so I think it is worth the wait for a clean solution.
I also think the jikes-kaffe, etc proposals are silly: You should
be able to achieve the same with a simple "jikes -bootclasspath
(In principle, I think that extdirs should be handled in the same
way. However, I'm not sure I understand its purpose, and I'm not
sure Debian should support it at all.)
To UNSUBSCRIBE, email to email@example.com
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org