Dynamic class loading

Sat Apr 1 00:00:00 GMT 2000

Per Bothner wrote:
> 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.

This makes sense since it is somewhat different to the way LD_LIBRARY_PATH is
used currently, where each of the directories in the list are searched for .so
files matching a certain pattern. But why is it necessary to use the CLASSPATH
var to do this? Why not GCJ_CLASSPATH or some such? If gcj itself needs to be
changed to ignore .so files on the classpath, then there are doubtlessly other
java compilers and runtimes that are going to complain (or worse, break) if they
find strange files on their classpath. Then again I'm not sure we want too many
different ways of potentially loading classes, I already have enough trouble
sometimes with stale .class files lurking on my classpath somewhere.
Its also worth remembering that we're allways going to need to keep .class files
around in CLASSPATH for compilation purposes. It would be annoying, or at least
strange, to be able to execute classes but not actually compile against them.
Although, if its indeed possible to compile .java source directly against .so
files, that would be a very cool feature!
> 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.

Well, Tom's existing method doesn't need hacks like this. The classloader doesn't
need to load java-awt.so until a java.awt class is requested.
> > 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.

Loading class files from .so's is not something Sun have ever done. People
porting applications from traditional VM environments are going to have to adapt
to things like this regardless. CLASSPATH has been one of the biggest flaws and
source of problems in traditional VMs (which is why Sun have worked around it
somewhat in JDK 1.2 with things like the extensions directory, executable .jars,
etc). I'd like to think we can come up with something better for gcj.
regards
 [ bryce ]