What classes are in a package?

[Glenn McCall]

Given a package name, is it possible to determine (via Java code) what
classes are defined within a package?

 

[Chris Smith]

Given a package name, is it possible to determine (via Java code) what
classes are defined within a package?

No, and I just told you that in comp.lang.java.help. If you would
please crosspost instead of multiposting, then this question would have
only needed to be answered once, and you wouldn't have as many places to
look for answers. It makes it easier for everyone.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Roedy Green]

Given a package name, is it possible to determine (via Java code) what
classes are defined within a package?

If you have a main class name, you can fetch that class, the study the
class and find references to other classes, which lead to still more
references. This still would only tell you about classes USED, not
written. It would not tell you about classes dynamically loaded via
class.forName

 

[Joseph Dionne]

By "package name" do you mean a .jar? If so, a long way around would be
to read the jar, jar tvf name.jar, and reflect into each class.

 

[Glenn McCall]

Well it *could* be a jar.

What I mean is given a name like "java.util.*" can I get a list of classes
that are in that package.

For example given java.util.* I want to obtain a list like this:
AbstractCollection
AbstractList
AbstractMap
AbstractSequentialList
etc

With or without package names. That is either "AbstractCollection" or
"java.util.AbstractCollection" are fine.

 

[Glenn McCall]

What I am trying to achieve is a program that looks for classes in a
particular package.
For each class that it finds in the package I will check that it is derived
from an abstract class (or inteface) that I will define. If it is derived
from my base class I will make it available for a user to use.

Specifically, my program will have a drawing area. If the user "alternate
mouse" clicks on the drawing area, a popup menu will appear with a New item.
The New item will have a list of classes that are found in the package that
I define that are derived from my base class.

From the "user" perspective, to add functionality to my program all they
need to do is extend my base class/interface and declare the class to be
part of the package that I nominate.

Hence the original question can I get a list of classes that are defined in
a specific package?

Obviously other solutions are possible - for example XML file that describes
the classes I can load.
However, I want to try and make the distribution of extensions to be as
simple as compiling a class into a package if I can.

TIA

 

[Mark Haase]

Hence the original question can I get a list of classes that are defined in
a specific package?

Obviously other solutions are possible - for example XML file that describes
the classes I can load.
However, I want to try and make the distribution of extensions to be as
simple as compiling a class into a package if I can.

TIA

AFAIK, you cant walk a package hierarchy, you must know all the packages
you want to use by name, in advance. Most plugins work by having a
plugins folder. You can scan the folder for *.class files at init, and
test each one to see if it conforms to the public interface you're
looking for.

 

[Chris Smith]

From the "user" perspective, to add functionality to my program all they
need to do is extend my base class/interface and declare the class to be
part of the package that I nominate.

They'll also need to put the code somewhere that the program can find
it, right? Otherwise, you're asking for magic from the Java
implementation. You need to start from that angle: where is the code
for these classes? Find them there, and then once you've found the
implementation code, you can turn around and check the package for the
appropriate value if you still want to require that the classes be in a
specific package (but that actually seems like a bad idea to me -
packages do have a purpose).

You'll also find that things get cleaner and easier if you load the
classes in a new class loader (a URLClassLoader with an appropriate
file-scheme URL should work fine).

Hence the original question can I get a list of classes that are defined in
a specific package?

That question has been answered more times than I can count. Is there
something you don't understand about the answer, or do you just think
the answer will change if you keep asking?

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Andrew Thompson]

...

That question has been answered more times than I can count. Is there
something you don't understand about the answer, or do you just think
the answer will change if you keep asking?

Your pateince, Chris, is admirable. ;-)

 

[Glenn McCall]

Thoughts embedded below....

They'll also need to put the code somewhere that the program can find
it, right? Otherwise, you're asking for magic from the Java
implementation. You need to start from that angle: where is the code
for these classes? Find them there, and then once you've found the
implementation code, you can turn around and check the package for the
appropriate value if you still want to require that the classes be in a
specific package (but that actually seems like a bad idea to me -
packages do have a purpose).

Agreed, but the code supplied will have to be within the scope as defined by
the classpath. Indeed it could be in any directory or set of directories
that correspond to the classpath.
For example if I define a classpath as "/classpath:/~/classpath" and I
define the name of the package that I am going to scan as
"com.mycorp.myapp.plugins" then the extension classes could be in
/classpath/com/mycorp/myapp/plugins/* or
~/classpath/com/mycorp/myapp/plugins/* or as I understand it (although
haven't tried) I could probably have some in the /classpath path and some in
the ~/classpath path.

I was thinking that by adopting this approach, extending my app would be as
simple as compiling a new class into whichever directory on the class path
you like. In this manner there is no restriction to a particular directory -
the plugins simply work if they are placed somewhere in the classpath in the
package I am looking for.

Absoulutely agree with what you say re the use of packagenames - it seemed
reasonable to me to define a "plugins" package for my app to organise them.

You'll also find that things get cleaner and easier if you load the
classes in a new class loader (a URLClassLoader with an appropriate
file-scheme URL should work fine).

I shall explore that - thanks

That question has been answered more times than I can count. Is there
something you don't understand about the answer, or do you just think
the answer will change if you keep asking?

Not really, I was providing more specific information in the hope someone
might say well you can't do exactly that but you could do this.
I am thinking the way I am going to have to tackle this is either restrict
to a particular directory or scan the directories listed in the classpath in
conjunction with my package name looking for .class files.

Shame, Java does so much, I thought/hoped it could do this as well.

 

[Dale King]

Thoughts embedded below....




Agreed, but the code supplied will have to be within the scope as defined by
the classpath. Indeed it could be in any directory or set of directories
that correspond to the classpath.
For example if I define a classpath as "/classpath:/~/classpath" and I
define the name of the package that I am going to scan as
"com.mycorp.myapp.plugins" then the extension classes could be in
/classpath/com/mycorp/myapp/plugins/* or
~/classpath/com/mycorp/myapp/plugins/* or as I understand it (although
haven't tried) I could probably have some in the /classpath path and some in
the ~/classpath path.

I was thinking that by adopting this approach, extending my app would be as
simple as compiling a new class into whichever directory on the class path
you like. In this manner there is no restriction to a particular directory -
the plugins simply work if they are placed somewhere in the classpath in the
package I am looking for.

Absoulutely agree with what you say re the use of packagenames - it seemed
reasonable to me to define a "plugins" package for my app to organise them.

I shall explore that - thanks
defined

Not really, I was providing more specific information in the hope someone
might say well you can't do exactly that but you could do this.
I am thinking the way I am going to have to tackle this is either restrict
to a particular directory or scan the directories listed in the classpath in
conjunction with my package name looking for .class files.

Shame, Java does so much, I thought/hoped it could do this as well.

It would have to be psychic to be able to do it completely.

I might suggest another alternative that works the way that JavaBeans do.
The JavaBeans spec allows you to package plugins into a jar and you know
what bean classes are in the jar because they are listed in the manifest
file for the jar:

http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html#Per-Entry Attribute
s

So the creator of the plug-in has to create a special jar file to indicate
which classes to look for in the jar. To use a plugin in your program the
user either selects the plug-in jars to use and/or puts them in a plug-ins
directory.

A slight variation on this is also defined in the Jar spec called the
service provider. All service provider defines is that you can put files
into a subdirectory of the META-INF directory.

Generating the files for the META-INF directory can be automated using the
xDoclet tool:

http://sourceforge.net/projects/xdoclet

 

[Glenn McCall]

I just can't resist.

.. defined

Your pateince, Chris, is admirable. ;-)

And yet my perserverence got much more than the original response from Chris
which was simply

No