Re: URL protocol handler classloader

[Steven Augart]

Jeroen Frijters wrote:
> Steven Augart wrote:
[....]
> > the ClassLoader's defaultSystemClassLoader method returns
> > a system class loader based on URLClassLoader.  And VMClassLoader's
> > getSystemClassLoader method by default returns
> > ClassLoader.defaultSystemClassLoader.  So our preferred solution
> > seems to have this dependency.
> >
> > Am I overlooking something?
>
>
> AFAICT, as long as the VM isn't trying to load any non-system classes
> there isn't any problem with the current code (and the fact that IKVM
> (and probaly others) uses it without any problems suggests that as
> well). I'm not against changing URL to use the context class loader (it
> seems like the right thing to do), I'm just pointing out that what
> you're seeing might be due to something else.

I actually haven't experienced this.  I never tried to have Jikes
RVM use ClassLoader.defaultGetSystemClassLoader.  I'm speaking from
my experience with Jikes RVM's old ApplicationClassLoader class,
which was based on URLClassLoader just as
ClassLoader.defaultSystemClassLoader is.

I think that the only reason why it worked in our case for so long
was because we were keeping around a previous instantiation of
the ApplicationClassLoader from boot image writing time.  It was just
sane enough to delegate everything upward, and since every class we
ever ask for is located in the bootstrap path, it never got around to
trying to actually do anything useful before it was replaced during the
boot process.  However, I have not investigated this hypothesis in enough
depth to be sure of it.