On Tuesday 02 December 2003 11:58, Jeroen Frijters wrote:
Robert Lougher wrote:
Looking at the code, the "default" system class loader (in gnu.java.lang...) simply delegates to the bootstrap loader - it doesn't implement findClass. Obviously, it's not difficult to write my own to parse and search the classpath (zip, jar, file...). However, is there any reason why I can't simply sub-class URLClassLoader, and construct a list of URLs? I've got a simple SystemClassLoader based on URLClassLoader and it seems to work OK.
I do the same and I've never noticed any problems with it (and I don't see any reasons why it should cause a problem). In fact, I think that Classpath should include an application and extension class loader based on this idea. It's on my TODO list, but the list is rather long ;-)
FWIW Wonka does this too. The only disadvantage I can see is that on interpreted systems it will tend to be a bit slower, which could be noticeable during start-up of an application. OTOH it's much cleaner and more flexible.
Kaffe does that too (kaffe.lang.AppClassLoader). The Java Security book by Li Gong also implies that the SystemClassLoader is an URLClassLoader. In fact, some applications (OpenEJB) expect that, and try to cast the system class loader to that type.
cheers, dalibor topic
_______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
