fix: Fix getOriginalSourceFragment and getRawJavadoc for zip file inputs #4850
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Previously, zip files were flattened and stored as `<name><random number>.java`. This caused all methods that retrieve code at runtime, such as getOriginalSourceFragment or getRawJavadoc, to fail. This patch keeps the structure of the zip file intact while extracting it into a temporary folder. Consequently, the aforementioned methods are now able to find the source files.
I-Al-Istannen
commented
Aug 19, 2022
| output.reset(); | ||
| try (FileSystem zip = FileSystems.newFileSystem(URI.create("jar:" + file.toURI()), Map.of())) { | ||
| Path tempFolder = Files.createTempDirectory("spoon-zip-file-proxy"); | ||
| // Try to clean up - not guaranteed to work! |
There was a problem hiding this comment.
This wasn't guaranteed before as well and depends on the mood of the JVM. File#deleteOnExit() which was used before in Sources also registers a shutdown hook.
| zipInput.transferTo(output); | ||
| files.add(new ZipFile(this, entry.getName(), output.toByteArray())); | ||
| output.reset(); | ||
| try (FileSystem zip = FileSystems.newFileSystem(URI.create("jar:" + file.toURI()), Map.of())) { |
There was a problem hiding this comment.
This can be made nicer in Java 13+, but for now we are stuck with it. URI.toString() should round-trip, so this should be safe for arbitrary paths.
| } | ||
| } catch (Exception e) { | ||
| Launcher.LOGGER.error(e.getMessage(), e); | ||
| Launcher.LOGGER.error("Error copying zip file contents", e); |
There was a problem hiding this comment.
LOGGER.error crashes with null messages, which is not ideal if you are trying to log such a message.
I-Al-Istannen
changed the title
SirYwell
reviewed
Aug 21, 2022
intrigus
reviewed
Aug 25, 2022
MartinWitt
approved these changes
Sep 11, 2022
MartinWitt
changed the title
|
Thanks @I-Al-Istannen |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description of the problem
Previously, zip files were flattened and stored as
<name><random number>.java. This caused all methods that retrieve codeat runtime, such as
getOriginalSourceFragmentorgetRawJavadoc,to fail.Chosen solution
This patch keeps the structure of the zip file intact while extracting it into a temporary folder. Consequently, the aforementioned methods are now able to find the source files.
There were multiple ways to proceed here. As JDT needs a copy anyways, I chose to proactively copy the files to disk instead of storing them in memory and copying them when the sources are prepared. Then I set
isActualFileto true, tricking the relevant parts of spoon into treating the zip file as a regular file (which it mostly is by now, as it has an on-disk representation). The old constructor is kept in place (but will cause problems) as the class is public. Nobody should have used it in the first place, so maybe we could also delete it?Instead of changing the folder structure we could change the compilation unit name named passed to JDT, This sounds a bit deadly and is also absolutely not compatible with existing code looking at the compilation unit layer. Every compilation unit would be named
/tmp/MyClass381891.javaor similiar, which is not that helpful.Further possible features
Allow the user to specify where the temporary files should be stored when creating a
ZipFolder. This can be easily retrofitted in the future though.