classpath
[Top][All Lists]
Advanced

[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: Sun, 16 Jan 2005 21:31:54 -0500
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041217

Mark Wielaard wrote:
Hi,

On Sun, 2005-01-16 at 10:09 -0500, Steven Augart wrote:

I don't think we should use the application classloader as backup
in every case.  Remember, the application class loader may not be
available or working at this phase in the booting process
-- and it won't be if someone is actually using Classpath's
defaultSystemClassLoader!


But if your default System class loader depends on URL protocol handlers
not provided by your bootstrap classloader you are in trouble anyway.
Since there is no other way to load those then. In practise this is
almost always just the "file:" protocol or some runtime specific one
(like "libgcj:" for native compiled gcj code).


As a backup, make it legal for VMClassLoader.getSystemClassLoader()
to return null if the system class loader is not yet available at this
point in the boot sequence.  If it returns null, then that
should be OK -- we just call Class.forName with "null" as the class
loader, meaning to use the bootstrap classloader.

If at this point the system classloader is null then we are in trouble.
We set the context classloader to null during bootstrapping so we
already tried the bootstrap classloader to get the URL protocol handler.

Well, we're trying to make sure that we can set up an instance of URL
and URLClassLoader in two often-independent cases:
(1) boot time and
(2) after boot, if the context class loader (or one of its ancestors)
    is some user-written abomination that does not delegate upwards
    to the System Class Loader and ultimately to the Bootstrap Class Loader.

If every context class loader were guaranteed to delegate upward first,
then we'd have no reason to put in the backup plan (delegate to the system
class loader) at all.

And I agree that if we do the "check the system class loader as a backup"
step at a point in the boot sequence where the system classloader is null,
then it will be just as if we had no backup.  We will fail to find the
handler and have to err out with a failure to find the protocol handler.
I do not see any difference between that and the current situation.

I personally would prefer just to use the context class loader and then to
bail out if we can't retrieve with that, since class loaders are supposed
to delegate up the chain, all the way to the bootstrap class loader.
(Even if they don't, Jikes RVM, and other VMs such as Kaffe, have
hardcoded lists of bootstrap packages which are always given to the
bootstrap class loader; in our case, code in java.*,
gnu.classpath.*, gnu.java.*, com.ibm.JikesRVM.*, org.mmtk.*,
and org.vmmagic.* are bootstrap classes and must be loaded with
the bootstrap class loader.  However, unless someone can find a Java
standard that insists that this is absolutely required, it makes sense
for Classpath to try to work with all kinds of VMs, so I'm willing to
use the backup.   But I *do* want it to work correctly for a VM to create
a URLclassLoader while booting.  If we made it legal for VMClassLoader
.getSystemClassLoader to return a null while booting, then I would consider
having Jikes RVM switch to Classpath's defaultSystemClassLoader implementation.

--Steve Augart




reply via email to

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