Getting a list of Classes in a Package

[John W. Kennedy]

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.

I think you misunderstood my "get". I meant that, rather than

public String[] getClassNames(Package package) throws
UnsupportedOperationException

it would be wiser to define

public interface ClassnameFilter {
boolean accept (String name);
}

and

public String[] getClassNames(ClassnameFilter filter) throws
UnsupportedOperationException

thus covering a wider range of possible uses.

However, it occurs to me now that there /is/ a real gain to be found in
searching by package (because of directories), so I suppose

public String[] getClassNames(ClassnameFilter filter, Package package)
throws UnsupportedOperationException

and the original

public String[] getClassNames(Package package) throws
UnsupportedOperationException

would also be desireable.
--
John W. Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
-- Charles Williams. "Judgement at Chelmsford"
* TagZilla 0.066 * http://tagzilla.mozdev.org

 

[Chris Uppal]

However, it occurs to me now that there /is/ a real gain to be found in
searching by package (because of directories), so I suppose

public String[] getClassNames(ClassnameFilter filter, Package package)
throws UnsupportedOperationException

Might be a bit tricky if some of the classes in the package are loaded from the
local filesystem, or a JAR file, while the others are loaded be doing an HTTP
GET per class. (Or, of course, any of the other awkward sources for
classfiles.)

-- chris

 

[Mark Rafn]

If you read both my explanations, you would see that this is what I'm
trying to do

Then go for it. There's nothing stopping you.

and is more reason why I think Java should have things
in place to facilitate this.

I repeat:

The key is recognizing this as app- or classloader-specific, and writing the
code to do it rather than hoping for impossible general support from the core
Java libraries.

Java _DOES_ have things in place to support it. You can list files, create
classloaders that do special things, and use reflection to instantiate classes
once you've found them. It doesn't have magic "read my mind and do the right
thing" support, but that's probably a good thing, given the confused state of
most developer minds

 

[Mark Rafn]

Agreed. Writing a classloader that includes this functionality (or just
exposes some of the functionality of sun.misc.URLClassPath) would be helpful.
Go for it!

I'm against adding anything of the kind to ClassLoader.

Agreed. It might be useful as part of a specific ClassLoader, or as a
separable component that ClassLoaders can use.

 

[Mark Thornton]

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.

Even that isn't useful. For example URL class loaders can't (usually)
enumerate the content of directories so all they know about is classes
that have already been loaded. There may be other classes that could be
loaded, but they have no way of determining their names.

Mark Thornton

 

[Andrew Thompson]

On Mar 23, 4:32 am, (e-mail address removed) (Mark Rafn) wrote:
...

...It doesn't have magic "read my mind and do the right
thing" support, ..

I am still waiting on the implementation of the
static method..

/** Produces the correct result
@param theStuff can be any number of any object, or 'null' */
public static void doWhatIMeanNotWhatISay(Object[] theStuff) {
...

;-)

Andrew T.

 

[Mark Thornton]

I can't possibly agree with you. This is totally what reflection is
all about.

Not to mention I don't think it is fair that you insult the
intelligence of someone who submitted an RFE.

As a general facility to be added to ClassLoader, what you are asking
for is impossible. The java.net.URLClassLoader can be given a URL which
refers to a directory accessed via http. You can't usually enumerate the
content of such a directory. Therefore you can't find out what classes
are present at that location, yet if you know the name of one you can
load it.

There are two approaches to this issue which do work. For IDEs, you just
insist that any class sources which are to be enumerated are located in
places such as jar files or file system directories which can be
searched. For general applications, you create files listing all the
available implementations of an interface and place these files as
resources in the jar files that you create. The standard mechanism for
doing this is (as of Java 6) java.util.ServiceLoader.

Mark Thornton