Steven Augart wrote: > I have what I think is a strong argument for why we need to > use the context classloader. > > 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?
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. Regards, Jeroen _______________________________________________ Classpath mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpath
