bug: Spoon fails to index modules when loaded from file system #4052
Comments
|
Hi @I-Al-Istannen, thanks for the report. I believe there is a bug in the JDT compiler. I'll look for a minimal bug reproduction and if it can be solved from Spoon for the time being. |
|
@I-Al-Istannen, I can reproduce the incorrect |
|
I don't have a MWE, as I threw the jdk 16 source code at it and didn't trim it down. I could try to do that, if the JDK code is too much for you to work with. The code is just System.out.println(heading("Configuring spoon"));
Launcher launcher = new Launcher();
launcher.getEnvironment().setShouldCompile(false);
launcher.getEnvironment().disableConsistencyChecks();
launcher.getEnvironment().setOutputType(OutputType.NO_OUTPUT);
launcher.getEnvironment().setSpoonProgress(new ConsoleProcessLogger(launcher));
launcher.getEnvironment().setCommentEnabled(true);
launcher.getEnvironment().setComplianceLevel(15);
for (String path : config.getResourcePaths()) {
if (path.endsWith(".zip")) {
launcher.addInputResource(new ZipFolder(new File(path)));
} else {
launcher.addInputResource(path);
}
}
System.out.println("Spoon successfully configured\n");
System.out.println(heading("Building spoon model"));
CtModel model = launcher.buildModel();
System.out.println("Model successfully built\n"); |
|
I trimmed down the JDK to 56 files which reproduce the error, but I couldn't really delete any more with trial and error: Just not passing the modules is not an option, as other modular programs that require java classes don't quite like it apparently: I didn't have any trouble after dropping the hacky patch above - that seems to only be triggered by the JDK itself. |
Problem
Spoon can not index a folder containing multiple modules but can index a ZIP containing the exact same data:
The exact exception is:
Cause
The JDT's main method parses the arguments and detects the presence of
module-info.javafiles. For some reason (I have absolutely no clue why) it then assumes that all the input files are in this module and completly ignores the file paths and uses the first module it finds for every class. This then breaks JDT in interesting ways, as you can see in the stacktrace above.A bit more concrete, this generates a
pathtomodmap like this:Why it works with ZIP files
When using ZIP files, spoon will copy the ZIP file's contents to randomly named
Name<number>.javafiles. Therefore, JDT will not recognize themodule-info.javafiles and does not fall into the problematic codepath. This inspired the hack in the next section, as it seemed to work just fine ™️ with the zipfile and therefore without the module info file handling.Possible solutions
To hack around this I currently do not pass
module-info.javafiles as arguments to the JDT builder:This works but as I don't know why we were passing them and why JDT treats them the way it does I don't expect it to be stable enough to use.
Maybe you have some ideas how to solve this.
The text was updated successfully, but these errors were encountered: