Dynamic class loading

Sat Apr 1 00:00:00 GMT 2000

Tom Tromey <tromey@cygnus.com> writes:
> 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.

The proposal is to only load .so files listed in the (explicitly or
implicitly) CLASSPATH, or explicitly loaded using System.loadLibrary.
Still, there is a disadvantage in that you at least conceptuallly
have to load every .so file in the CLASSPATH at startup, even though
some .so files may be useless.
One compromize/efficiency hack: If a .so file or a .jar.zip file
has a name that matches a certain pattern, then we know that
it can only contain classes from packages matching that pattern.
For example, we can define a convention that library named
"ONLY$java$awt.so" can only contain classes in the package java.awt
or its sub-packages; hence the system classloader can defer loading
ONLY$java$awt.so until it actually needs a class in java.awt.
> 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.

No, these are found using the default (implied) CLASSPATH, just
like Sun's Java finds classes.zip (JDK 1.1) or rt.jar (JDK 1.2) 
using a default 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.)

It is worth looking at Sun's extension mechanism, specifically
"installed extensions". See:
http://www.javasoft.com/products/jdk/1.2/docs/guide/extensions/extensions.html
The basic idea is that all .jar files in a certain "magic" directory
are automatically added to the end of the CLASSPATH. If we have a .so
containing pre-compiled classes, it seems a natural "extension"
of the the Java2 extension model to also add all .so files in the same
magic directory to the CLASSPATH.
> I also don't think that the naming requirement is that big a burden.

Not necessarily, but I think it is less flexible. More importantantly,
it is inconsistent to how Sun does it, which would complicate people
porting applications and extensions to gcj.
> Now it occurs to me that we'd also have to teach gcj to ignore a .so
> in CLASSPATH. (Not a big deal.)

Actually, ideally you would not have gcj ignore a .so on the CLASSPATH;
you would gcj do a dlopen on the .so file, and get the class reflective
information from the loaded .so file. Of course this only works for .so
files in the host machine's archicture; it would also be more trouble
to implement than it is worth. So ignore .so files - or issuing a
warning, make more sense.
-- 
	--Per Bothner
per@bothner.com http://www.bothner.com/~per/