A ClassLoader not necessarily needs a class path at all. Only if you
implement your class loader that way (to search along a certain path for
a class). You could come up with completely different strategies, e.g. a
class loader which loads its classes from a database, some binary image,
or e.g. via a proprietary protocol over a serial line. Non of these
would require a search class path.

This is wrong in at least two ways. ClassLoaders delegate the other way
around. When a class is needed, the request is first delegated to the
ClassLoader's parent ClassLoader (which might further delegate it to its
parent etc.). Only when the parent fails (can't find the class), then
the actual class loader gets a shot at it.

Second, as already mentioned, a class loader is not required to work
with a search class path at all.

What plug-in? What purpose? Loading a plug-in? To load a plug-in, a
class loader has indeed to be able to find the plug-in. A well behaving
plug-in should then be self-contained. It should only rely on standard
classes and classes which are contained in the plug-in. The standard
classes are easily found by the system class loader. And since you
managed to find the plug-in and load its main class, it should also be
no problem to apply the same mechanism you used for this to find the
remaining specific classes of the plug-in.

In general, I don't see the point in implementing an own custom class
loader for loading plugins. You could require that plugins are supposed
to go into an application specific location and have that location in
the normal class path. Or you could use an URLClassLoader to load
plug-ins from all kinds of locations, including jars.

/Thomas

There must be some way that your application has been told about any
particular pluggin.  Maybe it searched some well-known directory for .JAR
files.
Maybe something more complicated.  Anyway, it must have been given some
starting data.

You use that data to create a classloader, and use that to load the pluggin.
That's to say that it's /your/ choice what kind of classloader to use, and
where/how it looks for the pluggin code.  E.g. if you had a directory into
which pluggins in the form of JARs could be dropped, then you'd create
classloader (probably an instance of java.net.URLClassLoader) for each JAR.

If the pluggin wants to use more classloaders then that it it's affair --
nothing to do with you -- but the classloader that loads the pluggin's "main"
class(es) will be the one that your code defines and creates.

   -- chris