Dynamic class loading

Sat Apr 1 00:00:00 GMT 2000

>>>>> "Godmar" == Godmar Back <gback@cs.utah.edu> writes:

Godmar> It seems that .so files should be treated more similar to .jar
Godmar> or .zip entries in a CLASSPATH than to a .class file. In
Godmar> fact, one simple solution would just be to allow .so files
Godmar> alongside .zip, .jar, or directory paths in a CLASSPATH var
Godmar> (or GCJ_CLASSPATH, as the case may be.) There shouldn't have
Godmar> to be any relationship between the name of the class being
Godmar> loaded and the name of the .so file, me thinks.
First, I don't have any problem changing the current implementation if
that is what we decide.
There are two reasons I like the way things are right now:
1. We don't load every .so around in order to find a given class.
2. We don't require the user to set his CLASSPATH to include every .so
installed on the system. For instance, suppose we package AWT as a
.so ("java-awt.so") and Swing as a .so ("javax-swing.so"). So then
the user has to add both of these to his CLASSPATH. But then if we
add another new package, everybody has to update CLASSPATH. With the
current scheme, we just have to arrange to have the properly-named
.so's appear in the appropriate directory. (For system packagers like
Debian or Red Hat, this means you can just drop the new .so into /lib
and everything will magically work.)
I also don't think that the naming requirement is that big a burden.
That said, I'm curious to know why you (& Per) think that putting the
.so into CLASSPATH is the way to go.
Now it occurs to me that we'd also have to teach gcj to ignore a .so
in CLASSPATH. (Not a big deal.)
Tom