Repository navigation
Latest version is buggy. #471
Description
When using this to decompile my own Java code for testing, it decompiles some things wrong.
For example when my code has a for loop like this:
for (int n = 0; n<1000000; n++)
I find that it is decompiled like this:
for (byte b = 0; b<100000; b++)
It both gets the data type wrong, and changes the variable name. And both of these issues are new. Not sure when they were introduced, but I remember there having a version that didn't have this either of these issues. And I know this is a bug for sure when it displays the wrong data type (and it only has this issue when the int is part of a for-loop, not in all contexts where an int is used). There's no way a correctly functioning decompiler would ever decompile an int-type variable as a byte-type variable. And this bug definitely did NOT exist in previous versions, or I would have noticed it and reported it much earlier.
Also it renames EVERYTHING. In my main function it is defined as:
public static void main(String[] args)
But when jd-gui decompiles it it shows it as being:
public static void main(String[] paramArrayOfString)
It didn't used to do that. That's useful (giving you hints about a variable by its name) for when you are decompiling obfuscated code like in Minecraft (and I've read that decompiling MC was the entire inspiration for making jd-gui in the first place), but when working on non-obfuscated code, it should have an option to disable the renaming of variables and function arguments. But this is something you definitely would want to turn off when debugging my own code (using the decompiler to see how Java sees my code after it's been compiled, to make sure it's the same as my actual source code, or at least equivalent to my source code). So I don't know if this is a bug, or a feature that they just forgot to add a setting that would let you enable or disable it.
But please fix these things.
Activity
BenHut1 commentedon Dec 8, 2025
Just downloaded all versions of this software from the releases here on Github. It seems the incorrectly decompiling of the int-type variable in the for-loop as a byte-type variable, was introduced way back in version 1.4.3 of jd-gui. It worked correctly. It further seems that I was misremembering about the renaming of varaiables and params to things like paramArrayOfString instead of keeping their original name, as it appears that no version ever did keep the original names of variables and function params.
But it's too bad that way back in version 1.4.3 this bug of decompiling int variables (when the variable is used as the iterator) in for-loops to byte variables was introduced, because a lot of things were added since then to make the app more stable and handle more things introduced in newer Java versions. But I unfortunately can't recommend any version of jd-gui newer than 1.4.2 (the last version that didn't have this bug), despite all the other advancements made in newer versions of jd-gui. And the reason for this is that if you want a program to be able to be recompiled, you will want all the data types to NOT be changed during decompilation, or that will BREAK the ability to recompile it (or at least the ability to recompile it into a bug-free app, as this changing of data types will at the very least introduce bugs into the app).
nbauma109 commentedon Dec 18, 2025
Variable names are generated like that (paramArrayOfString, ...) when there's no local variable table in
.classfiles, i.e. when they were compiled withjavacwithout-goption. The decompiler also reads from local variable type table, so when that's not available, it guesses the variable type (although the guess is wrong given the value of 100000). Whatever provider of those.classfiles you have probably decided to make it less easy to decompile by dropping the-goption.