[kaffe] JARPATH implementation

[Dalibor Topic]

Hi pancake,

pancake wrote:
> I was thinking about how to implement a simple way to add a lot of jar files
> without the fucking hard way of manual handling, and my idea looks like this
> simple script.
> 
> :---
> JARPATH="/usr/pkg/share/classpath:/usr/pkg/lib/java:$JARPATH"
> JARPATH=`echo $JARPATH | awk '{ gsub(/:/," "); print $0}'`
> 
> for A in $JARPATH ; do
> 	for B in `ls $A/*.jar 2> /dev/null` ; do
> 		CLASSPATH=$B:$CLASSPATH
> 	done
> done
> 
> echo $CLASSPATH
> :---
> 
> Well the main idea of JARPATH environment is something like CLASSPATH environ
> but instead pointing to JAR files, pointing to the dirs containing these files,
> like LD_LIBRARY_PATH does.

It looks useful as a workaround to the current problem of not being able 
to resolve Class-Path: manifest entries in JAR archives.

The trouble with the approach is that it may be too broad, though. You 
can easily end up having multiple versions of a JAR file on your 
classpath, which is quite likely to cause unexpected, hard-to-debug 
problems with large applications.

> It's very useful, and would be nice to patch 'bin/kaffe' script-wrapper to
> allow this feature.

I don't doubt it's useful. I'm just afraid that as 
/usr/pkg/share/classpath and /usr/pkg/lib/java fills up with jars you'd 
end up with a twisting maze of little packages, all the same. Is there 
some particular application that forces you to work around with JARPATH?

Unfortunately, some projects use CVS snapshot JARs  of other projects in 
their releases, some projects break binary compatiblity in their JAR 
releases, and so on. So if you undiscriminately put all JARS on the same 
CLASSPATH, you can have interesting problems, to say the least.

Beside, if you've got a few hundred JAR files in your repository, most 
of which you'll hardly need for each and every application, putting them 
all on a system-wide CLASSPATH could increase class loading time quite a 
bit, since the class loader needs to check all jars on classpath in 
sequence until it finds a class. That puts classes in xerces.jar, for 
example, in a rather unfavourable position ;)

In the long run, I'd rather propose to switch gradually to Classpath's 
ClassLoader code, fix whatever is broken with it, and extend it to 
support resolution of Class-Path: entries in the manifest. Then it would 
be much easier to run applications 'the way the developers intended'.

cheers,
dalibor topic