Dynamic class loading

Sat Apr 1 00:00:00 GMT 2000

 I see. 
So .so files always override CLASSPATH settings.
You'd have to delete them or remove them from your LD_LIBRARY_PATH
if you didn't want them to be looked at first. If you're a non-privileged
user and someone dropped javax-servlet.so in /lib, you couldn't test your
own ./javax/servlet/Servlet.class? (Is this so?)
This could of course be fixed by telling it how to ignore those
files. Sure, why not.
Regarding Kresten's suggestion that a class loader should decide:
I thought that .so files should only be used to resolve classes once
a class loader invoked findSystemClass(), i.e., only for classes in
the "primordial" bootstrap classloader path. 
Would it make sense to associate loaded classes in a .so file with a 
classloader as their defining loader? After all, because of the dumbness 
of dynamic linkers, you can't have multiple definitions in multiple 
namespaces anyway. I'm not sure though, it may be desirable, for instance
for purposes of unloading upon gcing the loader.
	- Godmar
>> Godmar> Could you summarize in a paragraph or two what the current
> Godmar> algorithm is?
>> Sure.
>> Suppose you are looking for a class quux.foo.bar.
> The system class loader will first look for a .so named quux-foo-bar.so.
> If that fails (either not found, or doesn't provide the class), it
> will look for quux-foo.so.
> Then it will look for quux.so.
>> If none of that works it will search for a .class file using
> CLASSPATH.
>> Tom
>