|
From: | Steven Augart |
Subject: | Re: URL protocol handler classloader |
Date: | Sun, 16 Jan 2005 21:44:39 -0500 |
User-agent: | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041217 |
Jeroen Frijters wrote:
Steven Augart wrote:
[....]
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?AFAICT, as long as the VM isn't trying to load any non-system classes there isn't any problem with the current code (and the fact that IKVM (and probaly others) uses it without any problems suggests that as well). I'm not against changing URL to use the context class loader (it seems like the right thing to do), I'm just pointing out that what you're seeing might be due to something else.
I actually haven't experienced this. I never tried to have Jikes RVM use ClassLoader.defaultGetSystemClassLoader. I'm speaking from my experience with Jikes RVM's old ApplicationClassLoader class, which was based on URLClassLoader just as ClassLoader.defaultSystemClassLoader is. I think that the only reason why it worked in our case for so long was because we were keeping around a previous instantiation of the ApplicationClassLoader from boot image writing time. It was just sane enough to delegate everything upward, and since every class we ever ask for is located in the bootstrap path, it never got around to trying to actually do anything useful before it was replaced during the boot process. However, I have not investigated this hypothesis in enough depth to be sure of it.
[Prev in Thread] | Current Thread | [Next in Thread] |