Re: ClassLoader initialization in _Jv_RunMain

[Mark Wielaard <mark at klomp dot org>]

Hi,

On Fri, 2003-11-14 at 00:48, Tom Tromey wrote:
> >>>>> "Bryce" == Bryce McKinlay <bryce@mckinlay.net.nz> writes:
> 
> Bryce> It would be great to get all this cleaned this all up, but I
> Bryce> suspect the classloader stuff is a can of worms that might be
> Bryce> dangerous to open prior to 3.4.
> 
> We have to do something, since the `-jar' bug is an important
> regression.  There's a PR for this.  I've been planning to look at
> it, probably next week.

Andreas is trying out a simple workaround for this. Just commenting out
the setTime() call in ZipEntry.setExtra(byte[]). Since this seems to be
the only call that can trigger a (Calender) resource load while
initializing the VMClassLoader.

If we don't want to really fix our classloader hierarchy then another
approach would be to make the VMClassLoader contructor less eager to
feed URLClassLoader all the URLs during the super(init()) call, but call
URLClassLoader.addURLs(init()) sometime later after the VMClassLoader
has completed initialization.

An even better approach could be to make URLClassLoader.addURL[Impl]()
lazy. At the moment it actually tries to setup the cache to
URLConnections immediately and this triggers the opening of the zip and
jar files (which is nasty when we are at that moment initializing the
VMClassLoader). Making it lazy and only setup/open the URLConnection
cache on actual use might even make starting up applications that use
lots of URLClassLoaders faster (but since only in rare cases the
resources and classes those URLs point to are then not used, it will
probably only move the loading to a little later point in the
application).

The best approach is still to rework our classloader hierarchy so that
VMClassLoader is not both the parent and child of a URLClassLoader
(through inheritance).

Cheers,

Mark

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