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 automatically compatible. 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 core libraries. 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 /wherever/kaffe/puts/Klasses.jar". (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.) Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
