Java - Find all the methods returning a specific type from classloader

I am looking for a way to find all the methods from all the classes from my classloader which returns some type. For example List.

I tried to use this library - https://github.com/ronmamo/reflections

Reflections reflections = new Reflections("com",new MethodParameterScanner());

        Set<Method> methodsReturn = reflections.getMethodsReturn(List.class);
        methodsReturn
                .forEach(c -> System.out.println(c.getDeclaringClass() + "-" + c.getName()));

But failed with this exception.

org.reflections.ReflectionsException: could not get type for name com.intellij.rt.execution.CommandLineWrapper$AppData.access
	at org.reflections.ReflectionUtils.forName(ReflectionUtils.java:312)
	at org.reflections.util.Utils.getMemberFromDescriptor(Utils.java:67)
	at org.reflections.util.Utils.getMethodsFromDescriptors(Utils.java:88)

Is there any other way to do this?

What you want is not possible. reflections is a leaky abstraction; a hack with no guarantees.

The problem is that ClassLoader is an abstraction which fundamentally only has the following singular operation available:

• Given a resource name, return all versions of this resource that the classloader can find; usually, almost always, this will be 0 or 1 items. A 'resource' is a URL; one that can guaranteed be turned into an InputStream by this loader.

That is it.

Note how there is no method to ask for a list of all resources, and as a consequence, any attempt to do 'get me all resources that have property X' from a classloader is broken. It's like trying to draw water from a stone. You can't get what aint there.

What the reflections hack does is inspect what kind of classloader it is. If it recognizes the classloader as a thing that gets resources from a place that does have an operation to list all (such as a jar file or filesystem directory), it'll obtain the underlying locations and do direct 'list' operations on those resources, but, if the classloader involved is not one that reflections recognizes, or is one that is not backed by a store that has a list operation, then reflections will either silently ignore it, or crash.

This leads to the inevitable conclusion: You don't want to do what you said you want to do; it is not supported by java.

Even if you accept that your program will fail unless only basic jar/dir based classloaders are used, what you're doing is turning java into a structurally typed language. Java isn't structurally typed; it is designed around nominal typing. Not only does java just work better if you follow suit, you're doing things which other people writing java code assume never happen.

For example, if you go: "I am looking for all sorts of cameras, so I will just scan the entire classpath for any class that has a method with signature void shoot(Person p) and offer this in a list of options for making selfies", then you're going to have an extremely bad time when somehow the class Gun ends up in your classpath.

In java, two methods fundamentally do not relate, whatsoever, even if they have the same name - a method is defined by the ENTIRE signature, including the type it is in. This fact is all over java's language design.

So, how do you do things like this in java?

What you probably want is SPI.

• SPI is 100% compatible with all classloaders, now and forever.
• Java itself uses SPI in many places.
• SPI is common enough that there are plugins and tools built into many IDEs and build systems.
• It works solely on nominal typing.

Here's how SPI works:

• Define an interface or if you must, an (abstract) class.
• "Plugins" will be doing two things:
• [1] make a class that is instantiable (public, not abstract, has a public no-args constructor), [2] implements/extends that type we made in the first step, and [3] list the fully qualified name of this class in a file named META-INF/services/com.foo.full.package.name.ThatInterfaceFromStep1.

Then, the main tool does the following:

• Asks the classloader for all resources matching the name META-INF/services/com.foo.full.package.name.ThatInterfaceFromStep1, and then reads all lines from all of these.
• It then classloads each name it finds this way, and offers them as implementations. You can treat all of these as instances of ThatInterfaceFromStep1, because they are. No accidental lead poisoning possible.

You can use an annotation processor so that all you have to do is write, say:

@Provides(ImageSaver.class)
public class Jpg2000Saver implements ImageSaver {
    @Override public String description() {
        return "Joint Photographic Experts Group 2000 (JP2)";
    }

    @Override public void write(Image image, OutputStream target) throws IOException {
        // .... implement here
    }
}

and the associated annotation processor will take care of making that META-INF file for you. Alternatively, make that file yourself; e.g. if you use maven, put that in src/resources. To 'load' SPI files, that's built into java itself: ServiceLoader.