references on all Java classes within the same package

[Peter Parker]

Is it possible to get object references on all Java classes within the same
package without knowing their names? For example, I want to obtain the names
(hence, object references via Java reflection) of all the classes that are
contained inside package a.b.c knowing nothing else but the fact that they
are in that same package.

import a.b.c.*;

Is there a way to accomplish this? Thanks

 

[Andrew Thompson]

Is it possible to get object references on all Java classes within the same
package without knowing their names?

No. There are specific ways in specific cases, under limited
circumstances, but no general solution.

..For example, I want ..

What you want is not important, what you want to achieve
is somewhat more so. What do you want to *achieve*?

Andrew T.

 

[Manish Pandit]

There is none. You can get the packages known to the classloader, but
that is pretty much it. The packages do not have an accessor like
getClassesInPackage(). The 'Package' does not belong to reflection.

I did this to check it out...

Package[] arr = Package.getPackages();
for(Package item:arr){
System.out.println(item);
}

And I got a list of all packages that the classloder loaded, here is
the partial output:

package java.io, Java Platform API Specification, version 1.5
package javax.swing.undo, Java Platform API Specification, version 1.5
package java.lang, Java Platform API Specification, version 1.5
package java.net, Java Platform API Specification, version 1.5
package javax.sound.sampled, Java Platform API Specification, version
1.5
package sun.text, Java Platform API Specification, version 1.5
package java.text, Java Platform API Specification, version 1.5
package org.w3c.dom.events, Java Platform API Specification, version
1.5

....
-cheers,
Manish

 

[Ravi]

Yes and No. You can use the current classpath to open all Jars and all
files in directories that match your classpath. For Jars you need to
use the APIs available like JarFile or JarURLConnection or
JarInputStream class. The NO is because not all classes are created
from filesystems. A class generated from Rhino or Groovy or CGLib could
easily exist in a package and have no relationship to a filesystem at
all.

To solve this problem you will want to override a variety of
classloaders, which would also include the system class loader. This
requires a special JVM startup command line switch. Once you have the
system class loader you can detect when other class loaders are
created. When they are you need to modify their byte code to intercept
calls to loadClass or defineClass, just to know the names of the
classes they load. The whole system could get really messy, but for the
most part after doing all that, you could get all classes in a package.
Why?