Please feel free ;-)

I did warn that the technique was a little slow...

   -- chris

   It sounds like you haven't read the thread that I linked to. I don't
know why you might want to avoid reading that thread, but this post will
mainly be a regurgitation of what was written in that thread, since I'm
assuming you haven't read it. Your solution does not solve the problem
that the OP originally *stated* (though it probably solves the problem
that the OP originally *intended*).

   There is not a one-to-one correspondence between packages and
directories on computers. So for example, if you were using the "scan
directories" approach and were interested in all classes in package "foo",
it is not sufficient to merely scan directories named "foo" on your
computer. You'd also have to scan directories named "foo" on my computer,
and on computers which I may have thrown into black holes. (This is where
we initially, and incorrectly, concluded that it was completely
impossible).

   Later, it was decided that two classes are the same if they have the
same bytecode, even if they reside on different computers. E.g. if I write
a class on a computer, and then throw that computer into a black hole, and
you also write a class, and that class has the same bytecode as the class
that I wrote, then they are by definition the same class. (This is
philosophically comparable to the idea that if I write "3" on a piece of
paper, and you write "3" on a different piece of paper, we are both wrote
down the same number, the number itself being an abstract concept which is
not directly associated to either of our pieces of paper.)

   So one could write an iterator which returns every possible sequence
bytecode, much like you can iterate through every possible integer, and
turn the bytecode sequence into a Java class. Some of these bytecode
sequences might declare names that conflict with each other (e.g. there's
more than one class in package "foo" with the name "Bar", but they are
distinct classes, having different bytecode), and so you'd need to
separate these classes into different classloaders.

   Note that classes may "exist" in the "foo" package, even if they are
not stored on any local harddrive. This is philosophically comparable to
the idea that numbers "exists", conceptually, even if no one has ever
bothered to write them down yet.

   This is also why I suspect that the OP doesn't really want to load all
classes from a given package, but instead, wants to load all classes
located in a given local directory (perhaps with certain additional
conditions).

   - Oliver