I'm currently running Spring Boot 3.2.1 with Java 17, with Gradle 8.4 as a build tool and using Reflections 0.10.2 (latest version as of writing). Our project is a multi-module project, but for simplicity, assume we have 2 modules, with one module being the main, bootable module (boot jar) while the other module is something like a plugin and is not bootable. Gradle will end up building 2 different JARs, one being a Spring Boot bootable jar while the other will be a plain non-bootable jar.
We shall call the main bootable module as module A while the non-bootable module as module B.
In module A, there's an interface called IFoo. Module B will use IFoo to all the classes within, hence all given classes in module B have the same implemented methods. All given classes in module B are inside the same package, say xx.yy.zz. Module A will then scan module B for these classes via Reflections and attempt to execute them by looking at the same methods per IFoo.
Before that, module A and B were once a single module. While being a single module, creating a ConfigurationBuilder and targeting the package via forPackage() were done easily and Reflections were able to obtain all the classes successfully, as such:
var testPackage = "xx.yy.zz";
ConfigurationBuilder configurationBuilder = new ConfigurationBuilder()
.forPackage(testPackage)
.filterInputsBy(s -> s.contains(testPackage));
Reflections reflections = new Reflections(configurationBuilder);
Set<Class<?>> subTypes = reflections.get(SubTypes.of(IFoo.class).asClass());
Imagine if under xx.yy.zz, there's FooA and FooB, both implementing IFoo, the subTypes set will contain both these classes.
We then decided to split them out for modularity AS A REQUIREMENT (and hence ending up with 2 different jars as stated in the preface).
After splitting module A and B, the dependency between A and B can be described as one-way dependency, such that B is dependent on A because B imports IFoo from A to implement it in its classes under xx.yy.zz. For clarification, note that module A owns IFoo and module B doesn't (as B merely imports it from A). A is NOT dependent on B simply because A does not use B, but if module B (as a plain jar) is present, A will fire up Reflections to scan the classes from module B's jar, as such:
ClassLoader fooLoader = IFoo.class.getClassLoader();
URL url = new URL("jar:file:/<path to our plain plugin jar file>.jar!/");
URLClassLoader pluginLoader = URLClassLoader.newInstance(new URL[]{url}, fooLoader) // fooLoader as parent loader so that pluginLoader is aware of IFoo;
// test
var bool = scriptClassLoader.loadClass(IFoo.class.getName()).equals(IFoo.class); // returns true
... with some changes over in ConfigurationBuilder to add the plugin's class loader:
ConfigurationBuilder configurationBuilder = new ConfigurationBuilder()
.forPackage(testPackage, pluginLoader)
.filterInputsBy(s -> s.contains(testPackage));
... and calls the same subTypes = reflections.get(SubTypes.of(IFoo.class).asClass()) to obtain the resources.
If we call reflections.get(SubTypes.of(IFoo.class)), it is able to obtain FooA and FooB (.get() will return a set of String as .asClass() is currently not called) successfully. However, reflections.get(SubTypes.of(IFoo.class).asClass()) does not return anything at all. When module A and B were once a single module, this line would succeed but now when A and B are both different modules, it no longer works.
The class loader pluginLoader is fully aware of IFoo as its parent is fooLoader as per the code snippet above, hence the line scriptClassLoader.loadClass(IFoo.class.getName()).equals(IFoo.class) will return true. But regardless, asClass() will not work properly, seemingly not returning anything at all (subTypes will have a size of 0).
Help is much appreciated. Thanks in advance.
OK, so I've debugged for quite long now and finally reached a solution. The way Reflections operate is pretty confusing after all, as if anything that's configured with ConfigurationBuilder is "forgotten" after the initial initialization of the Reflections instance. Can't complaint though as it did help simplifying the entire reflection mechanism for us.
To those who stumbled upon similar question as I had, you shall re-apply the class loader (which contains the resources you want) while calling .asClass():
// your configuration builder
ConfigurationBuilder configurationBuilder = new ConfigurationBuilder()
.forPackage(testPackage, pluginLoader) // <<<
.filterInputsBy(s -> s.contains(testPackage));
Set<Class<?>> subTypes = reflections.get(SubTypes.of(IFoo.class).asClass(pluginLoader)); // <<<
Internally, passing the class loader into .asClass(), NameHelper.forClass() is called and will trigger the line classLoader.loadClass(type) (line 99) which is EXACTLY what we need. You'll figure out why calling .forClass() in a wrong condition yields the size of the Set to be 0 by looking at the next line, where Throwable is unfortunately ignored.