From: "Peter Donald" <[EMAIL PROTECTED]> > On Mon, 12 Nov 2001 10:38, Ted Neward wrote: > > > > really highlights a bug in the Java Class Libraries, and isn't an > > Ant-specific problem whatsoever--the default "parent" argument is always > > the System ClassLoader (the sun.misc.AppClassLoader), when it should be the > > ClassLoader of the class that's executing the current call > > (getCallerClassLoader()). > > God no - that would be horrible. Setting the parent to ClassLoader would > vastly increase the complexity of ClassLoader setups. This would break > virtually every EJB/servlet engine out there and cause massive portability > headaches. Coupling behaviour to the ClassLoader that happened to load the > Class would be a nightmare. We already have enough of these heaches dealing > with making sure dependent Classes are in current ClassLoader or parent > ClassLoaders. > > If you were to claim that all ClassLoaders use the ContextClassLoader then > that may be viable but can't ever change for backwards compatibility reasons.
There is one "funny" aspect of the documentation for URLClassLoader. If you read the Javadoc, it never says what is the default classloader. It just says "it will use the default ClassLoader as the parent". This is in contast with for example the ClassLoader class which states that "it will use the system classloader as the parent" (in the constructors where no parent is passed). So it sounds not too commital on their part or giving room for subclasses to do different. One thing we should provide (maybe as a replacement or evolution of AntClassLoader) or maybe as part of jakarta-commons is a subclass of URLClassLoader that uses the Thread context ClassLoader as the default ClassLoader. This is all ANT2 stuff since URLClassLoader is all JDK1.2 stuff. Jose Alberto -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
