How do you find all subclasses of a given class in Java

Question

How does one go about and try to find all subclasses of a given class  or all implementors of a given interface  in Java  As of now  I have a method to do this  but I find it quite inefficient  to say the least   The method is     Get a list of all class names that exist on the class path Load each class and test to see if it is a subclass or implementor of the desired class or interface   In Eclipse  there is a nice feature called the Type Hierarchy that manages to show this quite efficiently  How does one go about and do it programmatically

User · Answer

This is not possible to do using only the built-in Java Reflections API.

A project exists that does the necessary scanning and indexing of your classpath so you can get access this information...

Reflections

A Java runtime metadata analysis, in the spirit of Scannotations
Reflections scans your classpath, indexes the metadata, allows you to query it on runtime and may save and collect that information for many modules within your project.
Using Reflections you can query your metadata for:

get all subtypes of some type

get all types annotated with some annotation

get all types annotated with some annotation, including annotation parameters matching

get all methods annotated with some

(disclaimer: I have not used it, but the project's description seems to be an exact fit for your needs.)

User · Answer

Don t forget that the generated Javadoc for a class will include a list of known subclasses  and for interfaces  known implementing classes

User · Answer

If you intend to load all subclassess of given class which are in the same package  you can do so  public static List lt Class gt  loadAllSubClasses Class pClazz  throws IOException  ClassNotFoundException       ClassLoader classLoader   pClazz getClassLoader        assert classLoader    null      String packageName   pClazz getPackage   getName        String dirPath   packageName replace  quot   quot    quot   quot        Enumeration lt URL gt  srcList   classLoader getResources dirPath        List lt Class gt  subClassList   new ArrayList lt  gt         while  srcList hasMoreElements              File dirFile   new File srcList nextElement   getFile             File   files   dirFile listFiles            if  files    null                for  File file   files                    String subClassName   packageName         file getName   substring 0  file getName   length   - 6                   if    subClassName equals pClazz getName                           subClassList add Class forName subClassName                                                         return subClassList

User · Answer

It should be noted as well that this will of course only find all those subclasses that exist on your current classpath   Presumably this is OK for what you are currently looking at  and chances are you did consider this  but if you have at any point released a non-final class into the wild  for varying levels of  wild   then it is entirely feasible that someone else has written their own subclass that you will not know about   Thus if you happened to be wanting to see all subclasses because you want to make a change and are going to see how it affects subclasses  behaviour - then bear in mind the subclasses that you can t see   Ideally all of your non-private methods  and the class itself should be well-documented  make changes according to this documentation without changing the semantics of methods non-private fields and your changes should be backwards-compatible  for any subclass that followed your definition of the superclass at least

User · Answer

It should be noted as well that this will of course only find all those subclasses that exist on your current classpath   Presumably this is OK for what you are currently looking at  and chances are you did consider this  but if you have at any point released a non-final class into the wild  for varying levels of  wild   then it is entirely feasible that someone else has written their own subclass that you will not know about   Thus if you happened to be wanting to see all subclasses because you want to make a change and are going to see how it affects subclasses  behaviour - then bear in mind the subclasses that you can t see   Ideally all of your non-private methods  and the class itself should be well-documented  make changes according to this documentation without changing the semantics of methods non-private fields and your changes should be backwards-compatible  for any subclass that followed your definition of the superclass at least

User · Answer

Depending on your particular requirements  in some cases Java s service loader mechanism might achieve what you re after   In short  it allows developers to explicitly declare that a class subclasses some other class  or implements some interface  by listing it in a file in the JAR WAR file s META-INF services directory  It can then be discovered using the java util ServiceLoader class which  when given a Class object  will generate instances of all the declared subclasses of that class  or  if the Class represents an interface  all the classes implementing that interface    The main advantage of this approach is that there is no need to manually scan the entire classpath for subclasses - all the discovery logic is contained within the ServiceLoader class  and it only loads the classes explicitly declared in the META-INF services directory  not every class on the classpath    There are  however  some disadvantages    It won t find all subclasses  only those that are explicitly declared  As such  if you need to truly find all subclasses  this approach may be insufficient  It requires the developer to explicitly declare the class under the META-INF services directory  This is an additional burden on the developer  and can be error-prone  The ServiceLoader iterator   generates subclass instances  not their Class objects  This causes two issues    You don t get any say on how the subclasses are constructed - the no-arg constructor is used to create the instances  As such  the subclasses must have a default constructor  or must explicity declare a no-arg constructor     Apparently Java 9 will be addressing some of these shortcomings  in particular  the ones regarding instantiation of subclasses    An Example  Suppose you re interested in finding classes that implement an interface com example Example   package com example   public interface Example       public String getStr        The class com example ExampleImpl implements that interface   package com example   public class ExampleImpl implements Example       public String getStr             return  ExampleImpl s string              You would declare the class ExampleImpl is an implementation of Example by creating a file META-INF services com example Example containing the text com example ExampleImpl   Then  you could obtain an instance of each implementation of Example  including an instance of ExampleImpl  as follows   ServiceLoader lt Example gt  loader   ServiceLoader load Example class  for  Example example   loader        System out println example getStr           Prints  ExampleImpl s string    plus whatever is returned    by other declared implementations of com example Example

User · Answer

There is no other way to do it other than what you described  Think about it - how can anyone know what classes extend ClassX without scanning each class on the classpath   Eclipse can only tell you about the super and subclasses in what seems to be an  efficient  amount of time because it already has all of the type data loaded at the point where you press the  Display in Type Hierarchy  button  since it is constantly compiling your classes  knows about everything on the classpath  etc

User · Answer

This is not possible to do using only the built-in Java Reflections API.

A project exists that does the necessary scanning and indexing of your classpath so you can get access this information...

Reflections

A Java runtime metadata analysis, in the spirit of Scannotations
Reflections scans your classpath, indexes the metadata, allows you to query it on runtime and may save and collect that information for many modules within your project.
Using Reflections you can query your metadata for:

get all subtypes of some type

get all types annotated with some annotation

get all types annotated with some annotation, including annotation parameters matching

get all methods annotated with some

(disclaimer: I have not used it, but the project's description seems to be an exact fit for your needs.)

User · Answer

It should be noted as well that this will of course only find all those subclasses that exist on your current classpath   Presumably this is OK for what you are currently looking at  and chances are you did consider this  but if you have at any point released a non-final class into the wild  for varying levels of  wild   then it is entirely feasible that someone else has written their own subclass that you will not know about   Thus if you happened to be wanting to see all subclasses because you want to make a change and are going to see how it affects subclasses  behaviour - then bear in mind the subclasses that you can t see   Ideally all of your non-private methods  and the class itself should be well-documented  make changes according to this documentation without changing the semantics of methods non-private fields and your changes should be backwards-compatible  for any subclass that followed your definition of the superclass at least

User · Answer

Scanning for classes is not easy with pure Java    The spring framework offers a class called ClassPathScanningCandidateComponentProvider that can do what you need  The following example would find all subclasses of MyClass in the package org example package  ClassPathScanningCandidateComponentProvider provider   new ClassPathScanningCandidateComponentProvider false   provider addIncludeFilter new AssignableTypeFilter MyClass class        scan in org example package Set lt BeanDefinition gt  components   provider findCandidateComponents  org example package    for  BeanDefinition component   components        Class cls   Class forName component getBeanClassName            use class cls found     This method has the additional benefit of using a bytecode analyzer to find the candidates which means it will not load all classes it scans

User · Answer

I did this several years ago   The most reliable way to do this  i e  with official Java APIs and no external dependencies  is to write a custom doclet to produce a list that can be read at runtime   You can run it from the command line like this   javadoc -d build -doclet com example ObjectListDoclet -sourcepath java src -subpackages com example   or run it from ant like this    lt javadoc sourcepath    src   packagenames      gt     lt doclet name  com example ObjectListDoclet  path    build    gt   lt  javadoc gt    Here s the basic code   public final class ObjectListDoclet       public static final String TOP CLASS NAME     com example MyClass                    Doclet entry point         public static boolean start RootDoc root  throws Exception           try               ClassDoc topClassDoc   root classNamed TOP CLASS NAME               for  ClassDoc classDoc   root classes                      if  classDoc subclassOf topClassDoc                         System out println classDoc                                               return true                    catch  Exception ex                ex printStackTrace                return false                      For simplicity  I ve removed command line argument parsing and I m writing to System out rather than a file

User · Answer

I needed to do this as a test case  to see if new classes had been added to the code  This is what I did  final static File rootFolder   new File SuperClass class getProtectionDomain   getCodeSource   getLocation   getPath     private static ArrayList lt String gt  files   new ArrayList lt String gt     listFilesForFolder rootFolder      Test timeout   1000  public void testNumberOfSubclasses        ArrayList lt String gt  listSubclasses   new ArrayList lt  gt  files       listSubclasses removeIf s - gt   s contains  Superclass class         for String subclass   listSubclasses           System out println subclass             assertTrue  You did not create a new subclass    listSubclasses size    gt 1           public static void listFilesForFolder final File folder        for  final File fileEntry   folder listFiles              if  fileEntry isDirectory                  listFilesForFolder fileEntry             else               files add fileEntry getName   toString

User · Answer

The reason you see a difference between your implementation and Eclipse is because you scan each time  while Eclipse  and other tools  scan only once  during project load most of the times  and create an index  Next time you ask for the data it doesn t scan again  but look at the index

User · Answer

There is no other way to do it other than what you described  Think about it - how can anyone know what classes extend ClassX without scanning each class on the classpath   Eclipse can only tell you about the super and subclasses in what seems to be an  efficient  amount of time because it already has all of the type data loaded at the point where you press the  Display in Type Hierarchy  button  since it is constantly compiling your classes  knows about everything on the classpath  etc

User · Answer

It should be noted as well that this will of course only find all those subclasses that exist on your current classpath   Presumably this is OK for what you are currently looking at  and chances are you did consider this  but if you have at any point released a non-final class into the wild  for varying levels of  wild   then it is entirely feasible that someone else has written their own subclass that you will not know about   Thus if you happened to be wanting to see all subclasses because you want to make a change and are going to see how it affects subclasses  behaviour - then bear in mind the subclasses that you can t see   Ideally all of your non-private methods  and the class itself should be well-documented  make changes according to this documentation without changing the semantics of methods non-private fields and your changes should be backwards-compatible  for any subclass that followed your definition of the superclass at least

User · Answer

Keeping in mind the limitations mentioned in the other answers  you can also use openpojo s PojoClassFactory  available on Maven  in the following manner   for PojoClass pojoClass   PojoClassFactory enumerateClassesByExtendingType packageRoot  Superclass class  null         System out println pojoClass getClazz         Where packageRoot is the root String of the packages you wish to search in  e g   com mycompany  or even just  com    and Superclass is your supertype  this works on interfaces as well

User · Answer

I needed to do this as a test case  to see if new classes had been added to the code  This is what I did  final static File rootFolder   new File SuperClass class getProtectionDomain   getCodeSource   getLocation   getPath     private static ArrayList lt String gt  files   new ArrayList lt String gt     listFilesForFolder rootFolder      Test timeout   1000  public void testNumberOfSubclasses        ArrayList lt String gt  listSubclasses   new ArrayList lt  gt  files       listSubclasses removeIf s - gt   s contains  Superclass class         for String subclass   listSubclasses           System out println subclass             assertTrue  You did not create a new subclass    listSubclasses size    gt 1           public static void listFilesForFolder final File folder        for  final File fileEntry   folder listFiles              if  fileEntry isDirectory                  listFilesForFolder fileEntry             else               files add fileEntry getName   toString

User · Answer

You can use org reflections library and then  create an object of Reflections class  Using this object  you can get list of all subclasses of given class  https   www javadoc io doc org reflections reflections 0 9 10 org reflections Reflections html      Reflections reflections   new Reflections  my project prefix        System out println reflections getSubTypesOf A class

User · Answer

The reason you see a difference between your implementation and Eclipse is because you scan each time  while Eclipse  and other tools  scan only once  during project load most of the times  and create an index  Next time you ask for the data it doesn t scan again  but look at the index

User · Answer

Try ClassGraph   Disclaimer  I am the author   ClassGraph supports scanning for subclasses of a given class  either at runtime or at build time  but also much more  ClassGraph can build an abstract representation of the entire class graph  all classes  annotations  methods  method parameters  and fields  in memory  for all classes on the classpath  or for classes in selected packages  and you can query this class graph however you want  ClassGraph supports more classpath specification mechanisms and classloaders than any other scanner  and also works seamlessly with the new JPMS module system  so if you base your code on ClassGraph  your code will be maximally portable  See the API here

User · Answer

I m using a reflection lib  which scans your classpath for all subclasses  https   github com ronmamo reflections  This is how it would be done   Reflections reflections   new Reflections  my project    Set lt Class lt   extends SomeType gt  gt  subTypes   reflections getSubTypesOf SomeType class

User · Answer

Don t forget that the generated Javadoc for a class will include a list of known subclasses  and for interfaces  known implementing classes

User · Answer

Try ClassGraph   Disclaimer  I am the author   ClassGraph supports scanning for subclasses of a given class  either at runtime or at build time  but also much more  ClassGraph can build an abstract representation of the entire class graph  all classes  annotations  methods  method parameters  and fields  in memory  for all classes on the classpath  or for classes in selected packages  and you can query this class graph however you want  ClassGraph supports more classpath specification mechanisms and classloaders than any other scanner  and also works seamlessly with the new JPMS module system  so if you base your code on ClassGraph  your code will be maximally portable  See the API here

User · Answer

There is no other way to do it other than what you described  Think about it - how can anyone know what classes extend ClassX without scanning each class on the classpath   Eclipse can only tell you about the super and subclasses in what seems to be an  efficient  amount of time because it already has all of the type data loaded at the point where you press the  Display in Type Hierarchy  button  since it is constantly compiling your classes  knows about everything on the classpath  etc

User · Answer

There is no other way to do it other than what you described  Think about it - how can anyone know what classes extend ClassX without scanning each class on the classpath   Eclipse can only tell you about the super and subclasses in what seems to be an  efficient  amount of time because it already has all of the type data loaded at the point where you press the  Display in Type Hierarchy  button  since it is constantly compiling your classes  knows about everything on the classpath  etc

User · Answer

I know I m a few years late to this party  but I came across this question trying to solve the same problem   You can use Eclipse s internal searching programatically  if you re writing an Eclipse Plugin  and thus take advantage of their caching  etc   to find classes which implement an interface   Here s my  very rough  first cut     protected void listImplementingClasses  String iface   throws CoreException         final IJavaProject project    lt get your project here gt       try             final IType ifaceType   project findType  iface          final SearchPattern ifacePattern   SearchPattern createPattern  ifaceType  IJavaSearchConstants IMPLEMENTORS          final IJavaSearchScope scope   SearchEngine createWorkspaceScope          final SearchEngine searchEngine   new SearchEngine          final LinkedList lt SearchMatch gt  results   new LinkedList lt SearchMatch gt           searchEngine search  ifacePattern         new SearchParticipant    SearchEngine getDefaultSearchParticipant      scope  new SearchRequestor               Override         public void acceptSearchMatch  SearchMatch match   throws CoreException                     results add  match                        new IProgressMonitor               Override         public void beginTask  String name  int totalWork                                 Override         public void done                       System out println  results                        Override         public void internalWorked  double work                                 Override         public boolean isCanceled                       return false                      Override         public void setCanceled  boolean value                                 Override         public void setTaskName  String name                                 Override         public void subTask  String name                                 Override         public void worked  int work                                         catch  JavaModelException e               e printStackTrace                The first problem I see so far is that I m only catching classes which directly implement the interface  not all their subclasses - but a little recursion never hurt anyone

User · Answer

Keeping in mind the limitations mentioned in the other answers  you can also use openpojo s PojoClassFactory  available on Maven  in the following manner   for PojoClass pojoClass   PojoClassFactory enumerateClassesByExtendingType packageRoot  Superclass class  null         System out println pojoClass getClazz         Where packageRoot is the root String of the packages you wish to search in  e g   com mycompany  or even just  com    and Superclass is your supertype  this works on interfaces as well

User · Answer

Add them to a static map inside  this getClass   getName    the parent classes constructor  or create a default one  but this will get updated in runtime  If lazy initialization is an option you can try this approach

User · Answer

Don t forget that the generated Javadoc for a class will include a list of known subclasses  and for interfaces  known implementing classes

User · Answer

Add them to a static map inside  this getClass   getName    the parent classes constructor  or create a default one  but this will get updated in runtime  If lazy initialization is an option you can try this approach

User · Answer

If you intend to load all subclassess of given class which are in the same package  you can do so  public static List lt Class gt  loadAllSubClasses Class pClazz  throws IOException  ClassNotFoundException       ClassLoader classLoader   pClazz getClassLoader        assert classLoader    null      String packageName   pClazz getPackage   getName        String dirPath   packageName replace  quot   quot    quot   quot        Enumeration lt URL gt  srcList   classLoader getResources dirPath        List lt Class gt  subClassList   new ArrayList lt  gt         while  srcList hasMoreElements              File dirFile   new File srcList nextElement   getFile             File   files   dirFile listFiles            if  files    null                for  File file   files                    String subClassName   packageName         file getName   substring 0  file getName   length   - 6                   if    subClassName equals pClazz getName                           subClassList add Class forName subClassName                                                         return subClassList

User · Answer

I just write a simple demo to use the org reflections Reflections to get subclasses of abstract class   https   github com xmeng1 ReflectionsDemo

User · Answer

Scanning for classes is not easy with pure Java    The spring framework offers a class called ClassPathScanningCandidateComponentProvider that can do what you need  The following example would find all subclasses of MyClass in the package org example package  ClassPathScanningCandidateComponentProvider provider   new ClassPathScanningCandidateComponentProvider false   provider addIncludeFilter new AssignableTypeFilter MyClass class        scan in org example package Set lt BeanDefinition gt  components   provider findCandidateComponents  org example package    for  BeanDefinition component   components        Class cls   Class forName component getBeanClassName            use class cls found     This method has the additional benefit of using a bytecode analyzer to find the candidates which means it will not load all classes it scans

User · Answer

I did this several years ago   The most reliable way to do this  i e  with official Java APIs and no external dependencies  is to write a custom doclet to produce a list that can be read at runtime   You can run it from the command line like this   javadoc -d build -doclet com example ObjectListDoclet -sourcepath java src -subpackages com example   or run it from ant like this    lt javadoc sourcepath    src   packagenames      gt     lt doclet name  com example ObjectListDoclet  path    build    gt   lt  javadoc gt    Here s the basic code   public final class ObjectListDoclet       public static final String TOP CLASS NAME     com example MyClass                    Doclet entry point         public static boolean start RootDoc root  throws Exception           try               ClassDoc topClassDoc   root classNamed TOP CLASS NAME               for  ClassDoc classDoc   root classes                      if  classDoc subclassOf topClassDoc                         System out println classDoc                                               return true                    catch  Exception ex                ex printStackTrace                return false                      For simplicity  I ve removed command line argument parsing and I m writing to System out rather than a file

User · Answer

I m using a reflection lib  which scans your classpath for all subclasses  https   github com ronmamo reflections  This is how it would be done   Reflections reflections   new Reflections  my project    Set lt Class lt   extends SomeType gt  gt  subTypes   reflections getSubTypesOf SomeType class

User · Answer

Don t forget that the generated Javadoc for a class will include a list of known subclasses  and for interfaces  known implementing classes

User · Answer

Depending on your particular requirements  in some cases Java s service loader mechanism might achieve what you re after   In short  it allows developers to explicitly declare that a class subclasses some other class  or implements some interface  by listing it in a file in the JAR WAR file s META-INF services directory  It can then be discovered using the java util ServiceLoader class which  when given a Class object  will generate instances of all the declared subclasses of that class  or  if the Class represents an interface  all the classes implementing that interface    The main advantage of this approach is that there is no need to manually scan the entire classpath for subclasses - all the discovery logic is contained within the ServiceLoader class  and it only loads the classes explicitly declared in the META-INF services directory  not every class on the classpath    There are  however  some disadvantages    It won t find all subclasses  only those that are explicitly declared  As such  if you need to truly find all subclasses  this approach may be insufficient  It requires the developer to explicitly declare the class under the META-INF services directory  This is an additional burden on the developer  and can be error-prone  The ServiceLoader iterator   generates subclass instances  not their Class objects  This causes two issues    You don t get any say on how the subclasses are constructed - the no-arg constructor is used to create the instances  As such  the subclasses must have a default constructor  or must explicity declare a no-arg constructor     Apparently Java 9 will be addressing some of these shortcomings  in particular  the ones regarding instantiation of subclasses    An Example  Suppose you re interested in finding classes that implement an interface com example Example   package com example   public interface Example       public String getStr        The class com example ExampleImpl implements that interface   package com example   public class ExampleImpl implements Example       public String getStr             return  ExampleImpl s string              You would declare the class ExampleImpl is an implementation of Example by creating a file META-INF services com example Example containing the text com example ExampleImpl   Then  you could obtain an instance of each implementation of Example  including an instance of ExampleImpl  as follows   ServiceLoader lt Example gt  loader   ServiceLoader load Example class  for  Example example   loader        System out println example getStr           Prints  ExampleImpl s string    plus whatever is returned    by other declared implementations of com example Example

User · Answer

Scanning for classes is not easy with pure Java    The spring framework offers a class called ClassPathScanningCandidateComponentProvider that can do what you need  The following example would find all subclasses of MyClass in the package org example package  ClassPathScanningCandidateComponentProvider provider   new ClassPathScanningCandidateComponentProvider false   provider addIncludeFilter new AssignableTypeFilter MyClass class        scan in org example package Set lt BeanDefinition gt  components   provider findCandidateComponents  org example package    for  BeanDefinition component   components        Class cls   Class forName component getBeanClassName            use class cls found     This method has the additional benefit of using a bytecode analyzer to find the candidates which means it will not load all classes it scans

User · Answer

The reason you see a difference between your implementation and Eclipse is because you scan each time  while Eclipse  and other tools  scan only once  during project load most of the times  and create an index  Next time you ask for the data it doesn t scan again  but look at the index

User · Answer

Scanning for classes is not easy with pure Java    The spring framework offers a class called ClassPathScanningCandidateComponentProvider that can do what you need  The following example would find all subclasses of MyClass in the package org example package  ClassPathScanningCandidateComponentProvider provider   new ClassPathScanningCandidateComponentProvider false   provider addIncludeFilter new AssignableTypeFilter MyClass class        scan in org example package Set lt BeanDefinition gt  components   provider findCandidateComponents  org example package    for  BeanDefinition component   components        Class cls   Class forName component getBeanClassName            use class cls found     This method has the additional benefit of using a bytecode analyzer to find the candidates which means it will not load all classes it scans

User · Answer

This is not possible to do using only the built-in Java Reflections API.

A project exists that does the necessary scanning and indexing of your classpath so you can get access this information...

Reflections

A Java runtime metadata analysis, in the spirit of Scannotations
Reflections scans your classpath, indexes the metadata, allows you to query it on runtime and may save and collect that information for many modules within your project.
Using Reflections you can query your metadata for:

get all subtypes of some type

get all types annotated with some annotation

get all types annotated with some annotation, including annotation parameters matching

get all methods annotated with some

(disclaimer: I have not used it, but the project's description seems to be an exact fit for your needs.)

User · Answer

The reason you see a difference between your implementation and Eclipse is because you scan each time  while Eclipse  and other tools  scan only once  during project load most of the times  and create an index  Next time you ask for the data it doesn t scan again  but look at the index

User · Answer

I just write a simple demo to use the org reflections Reflections to get subclasses of abstract class   https   github com xmeng1 ReflectionsDemo

User · Answer

You can use org reflections library and then  create an object of Reflections class  Using this object  you can get list of all subclasses of given class  https   www javadoc io doc org reflections reflections 0 9 10 org reflections Reflections html      Reflections reflections   new Reflections  my project prefix        System out println reflections getSubTypesOf A class

User · Answer

This is not possible to do using only the built-in Java Reflections API.

A project exists that does the necessary scanning and indexing of your classpath so you can get access this information...

Reflections

A Java runtime metadata analysis, in the spirit of Scannotations
Reflections scans your classpath, indexes the metadata, allows you to query it on runtime and may save and collect that information for many modules within your project.
Using Reflections you can query your metadata for:

get all subtypes of some type

get all types annotated with some annotation

get all types annotated with some annotation, including annotation parameters matching

get all methods annotated with some

(disclaimer: I have not used it, but the project's description seems to be an exact fit for your needs.)

User · Answer

I know I m a few years late to this party  but I came across this question trying to solve the same problem   You can use Eclipse s internal searching programatically  if you re writing an Eclipse Plugin  and thus take advantage of their caching  etc   to find classes which implement an interface   Here s my  very rough  first cut     protected void listImplementingClasses  String iface   throws CoreException         final IJavaProject project    lt get your project here gt       try             final IType ifaceType   project findType  iface          final SearchPattern ifacePattern   SearchPattern createPattern  ifaceType  IJavaSearchConstants IMPLEMENTORS          final IJavaSearchScope scope   SearchEngine createWorkspaceScope          final SearchEngine searchEngine   new SearchEngine          final LinkedList lt SearchMatch gt  results   new LinkedList lt SearchMatch gt           searchEngine search  ifacePattern         new SearchParticipant    SearchEngine getDefaultSearchParticipant      scope  new SearchRequestor               Override         public void acceptSearchMatch  SearchMatch match   throws CoreException                     results add  match                        new IProgressMonitor               Override         public void beginTask  String name  int totalWork                                 Override         public void done                       System out println  results                        Override         public void internalWorked  double work                                 Override         public boolean isCanceled                       return false                      Override         public void setCanceled  boolean value                                 Override         public void setTaskName  String name                                 Override         public void subTask  String name                                 Override         public void worked  int work                                         catch  JavaModelException e               e printStackTrace                The first problem I see so far is that I m only catching classes which directly implement the interface  not all their subclasses - but a little recursion never hurt anyone

[java] How do you find all subclasses of a given class in Java?

Reflections

Examples related to java

Examples related to class

Examples related to interface

Examples related to subclass