Re: URL protocol handler classloader

[Steven Augart]

Mark Wielaard wrote:
> Hi,
>
> On Sat, 2005-01-01 at 16:01 +0100, Ewout Prangsma wrote:
>
> > Now; currently the URL class uses the system classloader to load 
> > protocol handlers.
> > Must this really be the system classloader?
> >
> > I have a protocol handler that is accessible via the context classloader 
> > (Thread.currentThread().getContextClassLoader()), but not via the system 
> > classloader. Is it possible to change this classloader arrangement so 
> > that the current context classloader is used?
>
>
> Yes. I implemented the current behavior in response to bug #9466
> (http://savannah.gnu.org/bugs/?func=detailitem&item_id=9466) which is
> still open since we seem to agree that using the context classloader
> would be the more correct option (falling back to the system/application
> classloader when that fails). See the bug report for some more
> discussion about this issue.

I have what I think is a strong argument for why we need to use the context
classloader.

What if someone is attempting to use the URL class in writing
their Application Class Loader (also known as the system class
loader)?  We get a serious recursion and bootstrap problem.
Jikes RVM (until yesterday) based its Application Class Loader
on Classpath's URLClassLoader, which in turn needs the URL Class.

When we're at the phase in the bootstrap process where we are
generating the application class loader, the current context
loader is the bootstrap class loader.  If URLClassLoader would use
only the bootstrap class loader, everything would be fine.  Instead, by
it insisting on the system class loader (application class loader),
we get a circular dependency.

Further, 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?

I have been thinking about this as part of getting Jikes RVM to work
with Classpath's CVS head.  The kludge I adopted was to take our
existing bootstrap class loader and tweak it a bit; it implements these
lookups without using the URL classes.

--Steve Augart