Unable to find classes implementing chosen interface if implementing super class is not in a scanned package

[classgraph]

Unable to find classes implementing chosen interface if implementing super class is not in a scanned package

[moldowan]

Have you read https://github.com/lukehutch/fast-classpath-scanner#detecting-annotations-superclasses-and-implemented-interfaces-outside-of-whitelisted-packages ?

While this explains the problem, I would rather just use MatchProcessors right away instead of having to collect the results afterwards and having to load the classes myself.
There has been a discussion before in #30

[czyzby]

Still, this seems rather unnecessary that you have to whitelist both the interface and all abstract classes that might be extended by your scanned types. While whitelisting all abstract classes is certainly an option, I'd expect the scanner to find _all_ classes implementing the chosen interface (even if indirectly), regardless of the location of the possible supertypes.

[lukehutch]

(Rather unfortunately) this is intended behavior, because to discover that ConcreteSearched implements Searched, you either have to scan both Searched and AbstractSearched (which defeats the original goal of searching only the package containing ConcreteSearched), or you have to call the classloader on either ConcreteSearched, or AbstractSearched, so that you can see these classes implement Searched (which defeats the whole point of FastClasspathScanner parsing the classfile binary format directly).

There is no reasonable way to fix this in FastClasspathScanner without entirely changing how FastClasspathScanner works, so that it calls the ClassLoader on each scanned class, which would be bad.

The right way to fix this in your code is to increase the coverage of the scan spec whitelist. Note that (as described in the link provided by mdolwan@) you can whitelist specific classes by name, not just packages, so in this case you can just call:

    new FastClasspathScanner(
            "package.containing.concretesearched",
            "otherpackage.Searched",
            "otherpackage.AbstractSearched").scan()

You said: "I'd expect the scanner to find all classes implementing the chosen interface (even if indirectly), regardless of the location of the possible supertypes." FastClasspathScanner does exactly that, as long as those classes are on a whitelisted path.

If you don't want to whitelist a path, you can just call FastClasspathScanner without any parameters (or with an empty path), and it will scan the entire classpath:

    new FastClasspathScanner("").scan()

Sorry I don't have a better fix than this (and have to mark this as closed), but calling the classloader while scanning is your enemy in the general case (class loading is time-consuming, and can trigger arbitrary static initializer code to run).

Keep the suggestions coming though, thanks for the report.