Cache (?) leads to no reaction for a changed jar file.

[Tao93]

it seems jd-gui uses cache or something. As a result, if I open a jar file with jd-gui, then change the jar file and open it with jd-gui again, there is no reaction for the change of that jar file in jd-gui. Only restarting jd-gui work. Any reply or explanation is appreciated. Thank you!

[Puspendert]

Facing the same issue on MacOs? Any resolution here?

[Simn]

I'm running into this as well. Is there a workaround?

[emmanue1]

Yes, JD-GUI uses a cache for each JAR, WAR, EAR, ZIP files. If you update a JAR file, close th tab, and drag and drop the new JAR file.

[Simn]

But that's the thing, closing the tab and dragging the changed JAR file in just shows the old version again.

[emmanue1]

Ok, I take a look.

[abbas-v1]

I just discovered this app and liking it, however because of this issue I am only limited to the jar xvf command. I wonder why would you need to use a cache of the jar.

[cdokolas]

This is still an issue with v1.6.6 :(
I have to close and re-open jd-gui every time I need to re-open the same jar file.

[EoinLawless]

I wasted three hours today - I'd been relying on jd-gui to confirm a jar had the expected changes. I closed all the tabs and reopened the file, but didn't restart jd-gui. At a minimum jd-gui should flag if a file has changed since the cache was last populated.

[bob0bob]

Yes, it is bad that when you close the jar file and drag a new one on it. it doesn't look at the new jar file. It just uses the old cache.

You can't rely on this unless you close it every single time.

[cddjr]

@Tao93 你提的这个bug也是我所困扰的，我的方案是在关闭面板时主动关闭jar文件的FileSystem即可解决。 具体可看 PR #293

[thecodewarrior]

I just spent four and a half hours bashing my head against Gradle builds, which then miraculously fixed itself, only for me to realize later that it was the fact that JD-GUI wasn't updating the file listing. It also explains why trying to look at the classes resulted in an // INTERNAL ERROR //.

[mtros]

Still got this issue on 1.6.6 - very annoying
any fixes soon? @cddjr

[kwin]

@emmanue1 I think you indeed just forgot to call https://docs.oracle.com/javase/8/docs/api/java/nio/file/FileSystem.html#close--. Not sure though whether calling at in the ContainerPanelFactoryProvider like proposed in #293 is corrrect. I would rather close it directly after usage in

jd-gui/services/src/main/java/org/jd/gui/service/fileloader/ZipFileLoaderProvider.java

Line 43 in b71cc56

fileSystem = FileSystems.getFileSystem(uri);

by using https://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html.

[VirajHasitha]

Still seeing this issue on 1.6.6 with ubuntu installation. Closing the JD-GUI won't help.

[hidetoshi-incorta]

I am not sure this is the same issue, but I see a very similar issue on 1.6.6 when I open my experimental jar that contains small changes for org.apache.hadoop.** classes.
I only see the original code, cannot see my changes on those classes.
Reopening JD-GUI and fix in #293 did not work.
After a half day, I found the root cause.
Seems from 1.6.6 there is a new feature to search source from Maven repository for some reserved classes that is enabled by default.
I disabled it from Preferences menu, and my issue disappeared.

[StevenJack666]

这是来自QQ邮箱的假期自动回复邮件。您好，我最近正在休假中，无法亲自回复您的邮件。我将在假期结束后，尽快给您回复。

[monkmachine]

I am not sure this is the same issue, but I see a very similar issue on 1.6.6 when I open my experimental jar that contains small changes for org.apache.hadoop.** classes. I only see the original code, cannot see my changes on those classes. Reopening JD-GUI and fix in #293 did not work. After a half day, I found the root cause. Seems from 1.6.6 there is a new feature to search source from Maven repository for some reserved classes that is enabled by default. I disabled it from Preferences menu, and my issue disappeared.

Thank you so much, disabled that option and now I can see my changes