What you ask is really out of my field, but I came to think of generics
wild cards the moment I read your post. Maybe that can be used somehow?

Good luck

There is no predefined way of achieving this. Class loaders are supposed
to supply the definition of a class X as soon as it is needed. They are
not intended for such queries, simply because the scope of your query is
undefined.
You probably mean all classes Y that implement interface X that are in
the classpath or something. That classpath is an artifact of the default
system class loader and as such is not a part of the Java language but
of its current implementation. If you would be using a class loader that
implements completely different class lookup logic the results would be
completely different.

If you are using the standard class loader then there is nothing that
keeps you from scanning the classpath, looking for .class files on it
and looking in all .tar and .zip files to see if the have .class files
in them. Load the classes you find and you can check if the implement X.

Kind regards,

Silvio Bierman

 A similar operation exists in the library »ram.jar«.
 This operation is based on Code by Ralf Ullrich.

 One can find all classes of a jar that have any chosen
 property, as long as this property can be obtained from the
 class reference.

 For example, to find all classes implementing »java.util.Map«,
 one sets a filter accepting only classes which
 »java.util.Map« is assignable from:

public boolean accepts( final java.lang.Class class_ )
{ return java.util.Map.class.isAssignableFrom( class_ ); }

 One also needs to provide a starting class to find the jar, which
 is done as follows.

public java.lang.String entryPath(){ return "java.lang.Object"; }

 The jar containing this type will be chosen for exploration.

 However, the client does not need to specify this »entryPath«,
 as "java.lang.Object" is the default obtained by extending
 »de.dclj.ram.java.lang.reflect.Finder.DefaultSpecification«.

 The example client is:

public class Main
{ /* based on an idea and on code by Ralf Ullrich from 2006 */

 public static void main( final java.lang.String[] args )
 { new de.dclj.ram.java.lang.reflect.Finder
   ( new de.dclj.ram.java.lang.reflect.Finder.DefaultSpecification()
     {
       public boolean isClassFinder(){ return true; }

       public boolean accepts( final java.lang.Class class_ )
       { return java.util.Map.class.isAssignableFrom( class_ ); }

       }).inspectJar(); }}

class java.lang.ProcessEnvironment
class java.rmi.server.RemoteObjectInvocationHandler$MethodToHash_Maps$1
class java.security.AuthProvider
(...)
class java.util.Properties
class java.util.Hashtable
interface java.util.Map

 The library »ram.jar« is an early publication in alpha state,
 it is experimental, changing, and mostly undocumented. See:

http://www.purl.org/stefan_ram/pub/ram-jar

the catch is, many of the classes you want are probably not even
loaded yet.  I think you will have to scan the byte codes of classes
on the classpath.

See http://mindprod.com/jgloss/javaclassformat.html

I have the same problem. This is the best answer I have found:

http://weblogs.java.net/blog/enicholas/archive/2006/04/creating_a_serv.html

Unfortunately, it depends on putting a properties file in your jar that
references the classes the implement the interface. Not ideal.

JDK 1.6 has a service provide interface that's worth looking at.

http://java.sun.com/javase/6/docs/api/java/util/ServiceLoader.html

If you find a more direct way, please post it here.