Skip to main content

Associative class searching

3 replies [Last post]
Joined: 2004-10-13

At present, the only way to find and load a class dynamically is (I believe) Class.forName(""). This makes useful plugin architectures possible, but not very clean. The problem is that you have to know the name of the class before you load it, which usually means specifying the name in some configuration resource somewhere, or (worse) hard-coding it. When you are creating an architecture which may contain a large number of pluggable components which you wish to dynamically load, this gets cumbersome, and introduces unnecessary dependencies. Consider the command pattern on a system with hundreds of commands, for instance.

What I would like to see instead is a method something like

Class[] Class.classesMatching(ClassPattern ...)

where ClassPatterns could exist for matching classes on a variety of criteria (name, package name, interfaces implemented, superclasses inherited, etc.) This method would return all classes loadable by the appropriate Classloader which match the given ClassPatterns. Plugin architectures become very simple to write and essentially auto-configuring. Obviously there are a lot of issues to resolve with this idea (security, instrumentation) but I think the basic idea has a lot of power.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2004-03-18

There is already a mechanism to do this.

It is specified in the jar spec

click on "Service Provider", I can't get the anchor into a url so it renders as a link in this forum because it has a space in it.

The example uses a class "Service", but doesn't show where it is. Thats a bit harder to find, but its called


Its undocumented, but you can see the method signatures with

javap sun.misc.Service

The new apt tool uses it for finding its factories, as does the java sound I think for loading its service providers.

In theory you shouldn't use sun.* classes, because they can change, so your requirement for Mustang should to move the sun.misc.Service functionality into the core API somewhere, and document, or stated another way "provide a mechanism to access the "Service Provider" functionality in the jar file spec.


Joined: 2003-06-13

I solved this by simply opening a jar; finding each entry and then loading that class via the URLClassLoader; using reflection you can find out if the needed interfaces/annotations etc are present.
Using the above classloader without a parent also allows you to do it in a sandboxed manner (statics are not even shared).

Its possible today.

Joined: 2004-10-13

This works if you are loading from a jar whose name and location you know. That seems questionable in various contexts, app servers in particular. There's nothing about classloading that demands that classes come out of jars, for that matter. It also seems like what you describe could be a performance sink if poorly implemented (a naive implementation of what you describe would be atrocious for use in an applet, for instance). Better to support this directly at the Classloader level, with a convenience static method on Class much like .forName(). That way classloaders could implement their own search and indexing mechanisms, if appropriate.