Re: Getting a list of Classes in a Package
John W. Kennedy 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.
Here is an alternative suggestion:
Add to ClassLoader a method:
public String[] getClassNames(Package package) throws
UnsupportedOperationException
....
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.
1) Might as well just get all classes, perhaps with a filter interface
similar to FilenameFilter.
Could you explain some more? A loadAllInPackage method seems to me to be
just as hard to implement, but less flexible. A user who wants to load
all the classes in the list could do so with a simple for loop.
In the specific case in which I wanted this, an end-user needed to pick
one class which would be used during the run. I would have liked to
offer a Choice, listing the available class names, rather than a TextField.
2) Consider interaction with sealed JARs.
That seems like a good reason for having the method in the class loader.
Presumably, it already has the ability to decide whether a .class file
is a legitimate candidate for loading given any sealing issues. A
duplicate implementation outside the class loader might easily miss that
sort of issue.
Patricia