Re: URL protocol handler classloader

[Mark Wielaard]

Hi,

On Sun, 2005-01-16 at 21:31 -0500, Steven Augart wrote:
> 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.

But it isn't. The context class loader is guaranteed to delegate upward
to the bootstrap classloader, but it doesn't have to have the
application/system classloader as (grand)parent.

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

Actually when you read about j2ee "application servers" you will find
they they deliberately break the delegation model to "facilitate"
upgrading/using different modules/packges.
http://www.theserverside.com/articles/article.tss?l=AdvancedClassLoading
(Note the use of the FireWall ClassLoader...)

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

I am still not sure why you think getSystemClassLoader() will be
triggered in the bootstrapping case. But feel free to supply a patch
either way. There are lots of applications out there the depend on
tricky interactions between ClassLoaders and URL protocol handlers (JXTA
and Eclipse for example) so we will quickly find out if we do something
right or wrong according to these applications anyway.

Cheers,

Mark

signature.asc
Description: This is a digitally signed message part