Re: Getting a list of Classes in a Package

From:

Patricia Shanahan <pats@acm.org>

Newsgroups:

comp.lang.java.programmer

Date:

Thu, 22 Mar 2007 07:37:28 -0700

Message-ID:

<etu4ba$1bie$1@ihnp4.ucsd.edu>

Omega wrote:

On Mar 22, 4:52 am, "Chris Uppal" <chris.up...@metagnostic.REMOVE-
THIS.org> wrote:

Patricia Shanahan wrote:

Some of the solutions other people have suggested duplicated the
directory and jar examination capabilities of the system class loader,
to see what it could load. I don't like that sort of duplication on
general software engineering principles.

I'm against adding anything of the kind to ClassLoader. My reason is that what
classloaders do is already widely misunderstood (by people who understandably,
but mistakenly, see Java through the static lens enforced by javac); and that
adding features which people expect to work in one way, when they actually work
in another, would be a mistake.

....

You're basically denying the obvious use of packages and "Class
LOADERS".

I mean, this domain & scope trollery is not going to help anything.
The best solution available is to allow an instance of Package to have
a method: "Class[] getClasses()" or "byte[] getEntries()".
This would spare you the need of bellyaching about burdening the
classloader (as the Java creators can implement this however they feel
needed) and it would put the code in the most obvious place:
Reflection. The implementation of everything else around it can be as
wild and correct as you envision.

The problem is that the question may be unanswerable. I can create, at
any time, a class that is a member of some package, and that could be
loaded by some specialized class loader that I have not, yet,
instantiated in a given program run.

Asking a class loader "What classes in this package do you currently
know how to load?" seems to me to be a much reasonable question.

Patricia