The latest revision of the CFCL fixes a fatal bug and is greatly simplified over the previous version.
The first version of was a lot more complex that it needed to be. In a misguided attempt to avoid a recursive loader invocation, I had ClasspathFileClassLoader extend ClassLoader, and used an inner class that extended URLClassLoader. This meant that CFCL should have obeyed the standard classloader rules of engagement, which it unfortunately didn’t.
Requests to the inner URLClassLoader were always made using findClass(), which (for all but the simplest of applications) will result in a ‘duplicate definition’ error when a load is requested for a class that has already been defined. What CFCL should have done is first issue a findLoadedClass() request, and only if that returned null attempt to load the class using findClass().
As it turns out, its not a problem have CFCL extend URLClassLoader; this greatly simplifies the code as the inner class is no longer necessary, and CFCL can simply rely on URLClassLoader to correctly implement the required class loader semantics. This also makes the class much easier to maintain because I no longer have to worry about managing resource loading, signers, etc; something I would have had to do had CFCL continued as a facade.
0 Responses to “classpath file classloader (++revision)”