I just did this ... get the classpath from System, for each entry in classpath iterate the files within, when you find a match on name + ".class" try to strip off the directory information and get the package name. I was only looking for classes in my system, so I could find the start of package name by "com" in the fully qualified filename.
You have to handle jars more or less like folders. I did not yet try to handle nested jars; you might have to extract the nested jar. This will mess up if you have the same classname in two packages.
Does that sound fun?
Letting clients invoke any class in your classpath sounds pretty dangerous. Back up to the real business requirement. Is this the best way to do it? I often have the client send in a logical name and look it up in configuration to get a classname. That gives me a bit more control over what the client can run.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
I second Stans suggestion to reexamine the requirements.
Also, there is no one-to-one correspondence between packages and classes, since the same class name can be in multiple packages (like "List" in the java class libraries).
Joined: Feb 23, 2007
Thank you all
Indeed, I need to know a list of all user classes with the specified name, at runtime. For example, for "List" it wold return "java.util.List", "java.awt.List" and so on, if those were classes in the web-inf\classes dir. Then, by reflection, I wold know wich one I should use.
A workaround I've just discovered for that, for a while, is running through servletContext.getResourcePaths("/WEB-INF/classes/"), recursively, and "catalogging" all ".class" found, replacing "/" whith "." to know its packages.
I'm just wondering there wasn't a simplier (less ugly) way to do that...