specific misunderstandings. Particularly, where/how the runtime finds
loader are at all available to classes loaded by the parent. I dont
think that part is true, but I'm seeking confirmation.
"chrislewis" <burningodzi...@gmail.com> wrote in message
news:1183576507.955550.103570@57g2000hsv.googlegroups.com...
I've done some brief searching through the JLS for information on how
exaclty new works - specifically, how the class supplied as an
argument is located (what class loader is used). I haven't found
anything yet, but in my readings I've come to assume that new must use
the class loader of the enclosing class. So if in my application's
main() method I call new MyClass(), the classloader that loaded the
class containing main() (the application class loader) is used to
resolve the class. Is this correct?
Further, I'm looking in to creating a pluggable architecture for my
app and will probably need at least a simple custom class loader.
Let's say I created JarClassLoader and use it within a class loaded by
the AppClassLoader. When I load classes using the JarClassLoader
(assuming that AppClassLoader is the parent of JarClassLoader),
classes loaded via JarClassLoader can have access to those loaded by
AppClassLoader (because its the parent), but the reverse is not true
(classed loaded via JarClassLoader are not available to the rest of
the app loaded by AppClassLoader). Is this correct? If not could
someone fill in the holes?
The behavior is entirely up to the class loader. In fact, the entire concept
of a "classpath" is simply an implementation feature of the default class
loader. I think your best bet will be to study the class loader class
hierarchy and see what they all do. If you need some custom behavior, you
can extend one of them, and link it into the chain.
In the few times I truly needed my own class loader, I extended
URLClassLoader, which will also load files (despite, or perhaps hence, it's
name).
See also:http://www.panix.com/~mito/articles/articles/classloader/j-classloade...