Nonsensical result when package prefix is name of actual class

[smillies]

ScanResult scanResult = new FastClasspathScanner(name).matchAllStandardClasses(System.out::println).scan();

will return a strange list of classes (perhaps from class path scanner itself?) when name is actually a class name (like java.util.HashMap).

The console output is attached. I would expect the scan result to be either empty or (preferably) to include the single given class, or an exception to be thrown.

-- Sebastian

output.txt

[smillies]

Additional observation: The effect goes away when I whitelist at least one package prefix in addition to the class name. In that case, the wrong output disappears and the class is listed along with the contents of the package. (Listing two different class names does not help).

[lukehutch]

Hi Sebastian, thanks for all these reports. I think what's happening here is that the items in the scan spec that are not specific class names is the empty set, so that means the entire classpath is scanned, and then the specific class name(s) in the scan spec are added to that whitelist.

That's non-intuitive, for sure, so maybe I should change the default here. However, other than not calling the ClassLoader, what advantage does using a single class name in the scan spec provide over Class.forName(name)? Or are you using a custom ClassLoader?

[smillies]

No custom classloader. I'm processing lists of scan specs and expand them into hash sets of class names. These sets are used to lookup whitelisted class names at runtime, for securing several remote protocols that require some sort of deserialization. (You can't very well match against FastClasspathScanner scan specs at runtime, constant time hash set lookup is better there). And I'm using FastClasspathScanner, because I want to avoid loading the class at that point (some of those static initializers might not do the right thing).

It just so happens that some of these incoming specs only contain a single class name. Currently, I work the default behavior by checking that special case myself and not calling scan() at all. As this is easy, there isn't really a problem, but perhaps changing the default behavior would make it less confusing.

[lukehutch]

Good catch, fixed this. This should work for you, but please test.

[smillies]

Thanks, works in current 2.0.4-SNAPSHOT.

[lukehutch]

Thanks for reporting and testing!

[lukehutch]

Released in version 2.0.4.