How can I enumerate all classes in a package and add them to a List?

Question

I need to enumerate all classes in a package and add them to a List. The non-dynamic version for a single class goes like this:

List allClasses = new ArrayList();
allClasses.add(String.class);

How can I do this dynamically to add all classes in a package and all its subpackages?

---

Update: Having read the early answers, it's absolutely true that I'm trying to solve another secondary problem, so let me state it. And I know this is possible since other tools do it. See new question here.

Update: Reading this again, I can see how it's being misread. I'm looking to enumerate all of MY PROJECT'S classes from the file system after compilation.

Codie

Why do you need to do this? Pardon me for asking, but it sounds like you might be asking for help in a secondary problem--which might not be the best way to attack your primary problem. – Sunfish

What are you trying to accomplish? Maybe you can use the Service Provider Interface to solve your problem. – Bogor

Related: #3923629 – Ryley

Related answer: https://mcmap.net/q/65000/-get-a-array-of-class-files-inside-a-package-in-java-duplicate – Jehanna

The most robust mechanism for scanning all classes in a package is ClassGraph (I am the author): github.com/classgraph/classgraph – Conversant

@MichaelMyers I'm trying to find all methods in all packages tagged with a @Test attribute (or implement an certain interface, or descend from a certain ancestor class). But Java's reflection system (unlike .NET) can't find methods or classes at runtime. Not only because Reflection won't know anything until a class has been loaded by a class-loader, but you need to know the name of the package at compile time (defeating the entire point of reflection). So we need a way to enumerate all packages, then use a class-loader to load them all, then use reflection to find @Test methods. – Prunella

Answer 1

****UPDATE 1 (2012)****

OK, I've finally gotten around to cleaning up the code snippet below. I stuck it into it's own github project and even added tests.

https://github.com/ddopson/java-class-enumerator

****UPDATE 2 (2016)****

For an even more robust and feature-rich classpath scanner, see https://github.com/classgraph/classgraph . I'd recommend first reading my code snippet to gain a high level understanding, then using lukehutch's tool for production purposes.

****Original Post (2010)****

Strictly speaking, it isn't possible to list the classes in a package. This is because a package is really nothing more than a namespace (eg com.epicapplications.foo.bar), and any jar-file in the classpath could potentially add classes into a package. Even worse, the classloader will load classes on demand, and part of the classpath might be on the other side of a network connection.

It is possible to solve a more restrictive problem. eg, all classes in a JAR file, or all classes that a JAR file defines within a particular package. This is the more common scenario anyways.

Unfortunately, there isn't any framework code to make this task easy. You have to scan the filesystem in a manner similar to how the ClassLoader would look for class definitions.

There are a lot of samples on the web for class files in plain-old-directories. Most of us these days work with JAR files.

To get things working with JAR files, try this...

private static ArrayList<Class<?>> getClassesForPackage(Package pkg) {
    String pkgname = pkg.getName();
    ArrayList<Class<?>> classes = new ArrayList<Class<?>>();
    // Get a File object for the package
    File directory = null;
    String fullPath;
    String relPath = pkgname.replace('.', '/');
    System.out.println("ClassDiscovery: Package: " + pkgname + " becomes Path:" + relPath);
    URL resource = ClassLoader.getSystemClassLoader().getResource(relPath);
    System.out.println("ClassDiscovery: Resource = " + resource);
    if (resource == null) {
        throw new RuntimeException("No resource for " + relPath);
    }
    fullPath = resource.getFile();
    System.out.println("ClassDiscovery: FullPath = " + resource);

    try {
        directory = new File(resource.toURI());
    } catch (URISyntaxException e) {
        throw new RuntimeException(pkgname + " (" + resource + ") does not appear to be a valid URL / URI.  Strange, since we got it from the system...", e);
    } catch (IllegalArgumentException e) {
        directory = null;
    }
    System.out.println("ClassDiscovery: Directory = " + directory);

    if (directory != null && directory.exists()) {
        // Get the list of the files contained in the package
        String[] files = directory.list();
        for (int i = 0; i < files.length; i++) {
            // we are only interested in .class files
            if (files[i].endsWith(".class")) {
                // removes the .class extension
                String className = pkgname + '.' + files[i].substring(0, files[i].length() - 6);
                System.out.println("ClassDiscovery: className = " + className);
                try {
                    classes.add(Class.forName(className));
                } 
                catch (ClassNotFoundException e) {
                    throw new RuntimeException("ClassNotFoundException loading " + className);
                }
            }
        }
    }
    else {
        try {
            String jarPath = fullPath.replaceFirst("[.]jar[!].*", ".jar").replaceFirst("file:", "");
            JarFile jarFile = new JarFile(jarPath);         
            Enumeration<JarEntry> entries = jarFile.entries();
            while(entries.hasMoreElements()) {
                JarEntry entry = entries.nextElement();
                String entryName = entry.getName();
                if(entryName.startsWith(relPath) && entryName.length() > (relPath.length() + "/".length())) {
                    System.out.println("ClassDiscovery: JarEntry: " + entryName);
                    String className = entryName.replace('/', '.').replace('\\', '.').replace(".class", "");
                    System.out.println("ClassDiscovery: className = " + className);
                    try {
                        classes.add(Class.forName(className));
                    } 
                    catch (ClassNotFoundException e) {
                        throw new RuntimeException("ClassNotFoundException loading " + className);
                    }
                }
            }
        } catch (IOException e) {
            throw new RuntimeException(pkgname + " (" + directory + ") does not appear to be a valid package", e);
        }
    }
    return classes;
}

Coriecorilla

Thanks for this code, has helped me a lot. I've found one small issue, however: if your resource URL has spaces in it, they get urlencoded (i.e. you end up with %20 in your path). When you construct your directory File with directory = new File(fullPath); , this causes directory.exists( ) to return false since it attempts to find a literal match to the encoded path. This can be solved by using directory = new File(resource.toURI()); instead (with appropriate exception handling). – Elwina

This doesn't work for packages that are located in JAR files as File doesn't work there. – Luane

@iDemmel - My use of File in the code is for the directory case. The JAR reading code uses JarFile. This code supports BOTH cases. Also, I've used it in a production system before and it worked in both cases. – Coriecorilla

@ddopson: It fails at new File(resource.toURI()), because the constructor will throw a "IllegalArgumentException: URI is not hierarchical" when it encounters a "jar:file:/opt/app/someDir/test.jar!/test/Test" kind of URI, which it encountered as my classpath is built with JAR files only. Look at this answer: #7575465 + I have encountered it myself using your code. – Luane

@iDemmel - strange that it worked on my distribution. The File class does indeed behave as you describe. download.oracle.com/javase/1.4.2/docs/api/java/io/…. Anyhow, I added a case to the code so that it will work with either behavior. Hopefully this fixes the issue for you... – Coriecorilla

@DaveDopson: there is a much simpler solution: Try to use ClassLoader.getResources( "test" ). It gives you a list of all resources in /test anywhere on the classpath. – Ryley

I get resource back as null. I'm calling the method as follows from the main method, having changed the mehtod's signature to getClassesForPackage(String pkgname) (so it takes a String instead of a Package: getClassesForPackage("com.example"); - having put the class into that package first, and exported it in Eclipse to a JAR file. I'm running the whole thing as java -cp test.jar com.example.naff.ClassFinder Please tell me I'm missing the obvious... – Insalubrious

@Insalubrious - can you file an issue on the github project? – Coriecorilla

@dave-dopson I can't reproduce that issue any more, but found a couple of others I just reported. However, after some inspection, it appears you might already have fixed them on your github version... Maybe it's worth highlighting that at the top of your post - or fixing them here, too...? :) – Insalubrious

It actually is possible to scan for all classes on the classpath in a given package, you just need to use a classpath scanner. See my separate answer on FastClasspathScanner. – Conversant

It's better if you paste the updated code into your stack overflow answer. – Paving

@AleksandrDubinsky - I haven't looked at this in a while... do you want to propose an edit? – Coriecorilla

Answer 2

The most robust mechanism for listing all classes in a given package is currently ClassGraph, because it handles the widest possible array of classpath specification mechanisms, including the new JPMS module system. (I am the author.)

List<String> classNames;
try (ScanResult scanResult = new ClassGraph().whitelistPackages("my.package")
        .enableClassInfo().scan()) {
    classNames = scanResult.getAllClasses().getNames();
}

Conversant

Answer 3

I figured out how to do this. Here's the procedure:

1. Start with a class in the root package, and get the folder it's in from the class loader
2. Recursively enumerate all .class files in this folder
3. Convert the file names to fully qualified class names
4. Use Class.forName() to get the classes

There are a few nasty tricks here that make me a bit uneasy, but it works - for example:

1. Converting path names to package names using string manipulation
2. Hard-coding the root package name to enable stripping away the path prefix

Too bad that stackoverflow doesn't allow me to accept my own answer...

Codie

You're right, but there are a huge number of complexities to deal with. See my answer about FastClasspathScanner. – Conversant

Answer 4

I'm afraid you'll have to manually scan the classpath and the other places where java searches for classes (e.g., the ext directory or the boot classpath). Since java uses lazy loading of classes, it may not even know about additional classes in your packages that haven't been loaded yet. Also check the notion of "sealed" packages.

Fireproof

Answer 5

It's funny that this question comes up every once in a while. The problem is that this keyword would have been more appropriately named "namespace". The Java package does not delineate a concrete container that holds all the classes in the package at any one time. It simply defines a token that classes can use to declare that they are a member of that package. You'd have to search through the entire classpath (as another reply indicated) to determine all the classes in a package.

Jealousy

Answer 6

There is a caveat to this: ApplicationEngines/servlet containers like tomcat and JBoss have hierarchical class loaders. Getting the system class loader will not do.

The way Tomcat works (things may have changed, but my current experience doesn't lead me to believe otherwise) but each application context has it's own class loader so that classes for application 'foo' don't collide with classes for application 'fooV2'

Just as an example. If all the classes got munged into one uber class context then you would have no idea if you were using classes appropriate for version 1 or version 2.

In addition, each one needs access to system classes like java.lang.String. This is the hierarchy. It checks the local app context first and moves it's way up (this is my current situation BTW).

To manage this, a better approach would be: this.getClass().getClassloader()

In my case I have a webservice that needs to do self-discovery on some modules and they obviously reside in 'this' webservice context or the system context. By doing the above I get to check both. By just getting the system classloader I don't get access to any of the application classes (and thus my resources are null).

Mohammadmohammed

Answer 7

Look at what java.net.URLClassLoader is doing. It never enumerates classes, it just tries to find classes when asked for one. If you want to enumerate the classes, then you will need to get the classpath, split it into directories and jar files. Scan the directories (and their subdirectories) and jar files for files with the name *.class.

It may be worth looking at open source projects which seem to do the enumeration you want (like Eclipse) for inspiration.

Treytri

Answer 8

If you are merely looking to load a group of related classes, then Spring can help you.

Spring can instantiate a list or map of all classes that implement a given interface in one line of code. The list or map will contain instances of all the classes that implement that interface.

That being said, as an alternative to loading the list of classes out of the file system, instead just implement the same interface in all the classes you want to load, regardless of package. That way, you can load (and instantiate) all the classes you desire regardless of what package they are in.

On the other hand, if having them all in a package is what you want, then simply have all the classes in that package implement a given interface.

Diazine