Re: CLASSPATH and Jikes
> I was just thinking of a simple way to set up my classpath so I made
> this suggestion. But if it is not common to do somthing like that, then
> I have to live with that. And maybe collecting all libs might not lead
> to the expected result, because of combining libs in different versions
> with the same classes in it. Then you need a script that checks the
> consistency of the classpath and warns when there are classes more
> then one time in the classpath
I'm beginning to think that we need a requires/provides database for java
libs or something. One thing I've noticed about JDK 1.4 is that there's a
lot of stuff now included in the basic package that used to be available as
a separate package. Javasoft's XML libraries are one example. So, with
previous versions of the JDK, you'd need to specifically include your XML
parsing libs... but you don't with JDK 1.4.
So, I'm wondering if it would be worthwhile for a Debian system to have a
database very similar to the dpkg database... describing which packages
depend upon which other ones... and which JVM's provide which packages
natively. That way, if I need the javax.xml libraries, my startup script
could include something like:
JVM="JDK1.3"
CLASSPATH=${CLASSPATH}:`require-java-library "$JVM" javax.xml`
When JVM is "JDK1.3", then the require-java-library script would return the
path to the jar that had the javax.xml tree in it. If JVM were "JDK1.4", the
script would return nothing at all, since the javax.xml stuff is included in
JDK1.4. This is kind of a crude example. I've got some other ideas that
would make this a bit slicker... but you get the idea.
This can help reduce the problem of multiple jars in the classpath having
the same packages. It should also reduce the number of unneeded jars in the
classpath... which can't hurt execution times.
- Joe
--
To UNSUBSCRIBE, email to debian-java-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: