[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: URL protocol handler classloader

From: Steven Augart
Subject: Re: URL protocol handler classloader
Date: Sat, 15 Jan 2005 22:55:04 -0500
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041217

Mark Wielaard wrote:

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
( 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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]