Re: Getting a list of Classes in a Package
Omega wrote:
....
I think anyone who is interested in having this issue solved and a
massively useful set of features made available to them in Java, they
should go and vote for the following bug/RFE:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4061452
It isn't far from getting enough votes for recognition, and I think
this functionality is well worth having.
I am strongly in favor of some solution to this problem, but doing it
through package reflection seems to me to limit its usefulness. As noted
in the response, it would only be able to find already loaded classes.
The problem is that what you really want is not what has been loaded,
but what could be loaded.
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.
Here is an alternative suggestion:
Add to ClassLoader a method:
public String[] getClassNames(Package package) throws
UnsupportedOperationException
If the method makes sense in a particular ClassLoader, it would search
as though it were looking for a class in the specified package, but list
all class names it has loaded or could load as classes in package.
The method would only find classes that have been loaded or could be
loaded by that particular class loader. It would not find classes that
exist on some disk drive, nominally in the package, but not loadable by
that class loader. It would not find classes that get copied into some
directory and become loadable after the call.
Some class loaders might not be able to implement this method, and would
throw UnsupportedOperationException. For example, an over-the-network
class loader might need to specify a complete class name, and not have
any interface to ask what could have been loaded.
In the simple case, with the system class loader, this would be
equivalent to searching the directories and jars on the class path, but
without the code duplication, and therefore automatically robust under
any changes in how the system class loader finds classes.
Patricia