The code that you use to test should test the features available the in JDK used to compile the target class. For example, if you know that your target is written in Java 1.5, it is reasonable to assume that the code might include generics, so you will want to make sure that your chosen decompiler handles them properly. In my experience, the freely available decompilers tend to lag behind the JDK releases in terms of the features they support by 1-2 releases.
Based on personal trial and error, JD tends to do the best job in general. However, if you're decompiling code that was written in 1.3 or lower, I'd also suggest you give JODE a try.
I have been using http://java.decompiler.free.fr/ for a long time now and found it to be the best one. In particular I used it to decompile a third-party jar and I was able to modify the source code as well with it.
Its easy to use and the UI is also neat and clean.
If you anticipate to get any meaningful results, you really should test with a bit more non-trivial code. Fernflower was created with the aim of handling highly unusual and obfuscated bytecode. Thus decompiling such simple snippets is no big deal. By the way, if you are interested in testing the stand-alone version of Fernflower drop me a note at fernflower(dot)decompiler(at)gmail(dot)com. Version 0.8.4 is now in semi-public beta (however not available on the website yet).
It looks like fernflower and JD Java Decompiler are producing decompiled code that is as good as is possible for this particular testcase. The other two aren't doing a good job, IMO.
What do you think, what code to write to test decompilers?
Write more complicated code using all available constructs.
Try them out on some real code.
Try them out on some real code that has been obfuscated.
When trying out code that you compile from source, experiment with different "-g" options, and with different Java compilers.
For information, JD supports switch(enum), switch(string), assert statements and for-each loops.
About the -g(javac) options,
if you omit the line numbers, JD can not reconstruct the original flow of instructions : the types of loop can not be determinate, the multiple assigments can not be regenerate, and the algorithm used to realign source code can not work.
if you omit the local variable data, JD can not, sometime, determine the exact range of variables. It's problematic.
Ok, this is written from my mobile phone so bear with me.
1st of all, every java file codes are compiled in bytecode in their respective .class file. This means that constants are stored AS IS (hence strings can easily be retrieved) and variables are assigned to a register that is then put on a stack program execution when the JVM process the class file.
The reason your exception block are not returned to the original code you've written is because of the way javac compiled & translated the code to java bytecode.
If you want to know which decompiler works best, write all java well known statements (for loop, if statement, while loop) with some expressions & see what best represent your original code.
It's been a while since any feedback to this thread. However since I found it and took the input seriously I feel it important to give an update.
I have used Java Decompiler Free with good success. However, recently I accidentally deleted quite a bit of code of a production J2EE application. assumed JD Free would handle it, but it doesn't handle generics at all. Plus there was code where it handled variable initialization totally wrong. What I ended up with was a total mess.
There may not be anything out there that will to the job correctly. In my case it's just another lesson in backup, backup, backup. I need a de-compiler that handles generics properly in order to do a mass recovery. But some accuracy of handling variables would also help. It is too much to ask a tool to spit out the original code. But what I have seen so far will compile but will not function properly, generics aside. So I suppose it's going to be a long week before Christmas!!
发布评论
评论（9）
用于测试的代码应该测试 JDK 中用于编译目标类的可用功能。例如，如果您知道您的目标是用 Java 1.5 编写的，则可以合理地假设代码可能包含 泛型，因此您需要确保您选择的反编译器能够正确处理它们。根据我的经验，免费提供的反编译器在支持的功能方面往往落后于 JDK 版本 1-2 个版本。
根据个人的尝试和错误，JD 总体上往往做得最好。但是，如果您要反编译用 1.3 或更低版本编写的代码，我还建议您提供 JODE 尝试一下。
编辑，5年后：
CFR，Procyon 和 Fernflower 在这个领域处于领先地位。
The code that you use to test should test the features available the in JDK used to compile the target class. For example, if you know that your target is written in Java 1.5, it is reasonable to assume that the code might include generics, so you will want to make sure that your chosen decompiler handles them properly. In my experience, the freely available decompilers tend to lag behind the JDK releases in terms of the features they support by 1-2 releases.
Based on personal trial and error, JD tends to do the best job in general. However, if you're decompiling code that was written in 1.3 or lower, I'd also suggest you give JODE a try.
EDIT, 5 years later:
CFR, Procyon, and Fernflower lead the way in this space.
Procyon 有 它自己的比较。
Procyon has it's own comparison.
我已经使用 http://java.decompiler.free.fr/ 很长时间了并发现它是最好的。特别是我用它来反编译第三方 jar，并且我还可以用它修改源代码。
它易于使用，用户界面也整洁干净。
更新：http://java.decompiler.free.fr/ 上不再提供 Java Decompiler 。它有新的链接http://jd.benow.ca/，可以从那里下载。
I have been using http://java.decompiler.free.fr/ for a long time now and found it to be the best one. In particular I used it to decompile a third-party jar and I was able to modify the source code as well with it.
Its easy to use and the UI is also neat and clean.
Update: Java Decompiler is no longer available on http://java.decompiler.free.fr/. It has new link http://jd.benow.ca/ from where it can be downloaded.
如果您期望获得任何有意义的结果，您确实应该使用更多不平凡的代码进行测试。 Fernflower 的创建目的是处理非常不寻常和混淆的字节码。因此，反编译这些简单的片段并不是什么大问题。顺便说一句，如果您有兴趣测试 Fernflower 的独立版本，请在 fernflower(dot)decompiler(at)gmail(dot)com 上给我留言。 0.8.4 版本现已处于半公开测试阶段（但尚未在网站上提供）。
If you anticipate to get any meaningful results, you really should test with a bit more non-trivial code. Fernflower was created with the aim of handling highly unusual and obfuscated bytecode. Thus decompiling such simple snippets is no big deal. By the way, if you are interested in testing the stand-alone version of Fernflower drop me a note at fernflower(dot)decompiler(at)gmail(dot)com. Version 0.8.4 is now in semi-public beta (however not available on the website yet).
看起来
fernflower和 JD Java Decompiler 生成的反编译代码与对于这个特定的测试用例是可能的。 IMO，另外两个做得不好。当尝试从源代码编译的代码时，请尝试不同的“-g”选项和不同的 Java 编译器。
It looks like
fernflowerand JD Java Decompiler are producing decompiled code that is as good as is possible for this particular testcase. The other two aren't doing a good job, IMO.When trying out code that you compile from source, experiment with different "-g" options, and with different Java compilers.
http://www.reversed-java.com/fernflower/，请参阅我在 github 上的比较.com /vorburger/ScratchApplet
http://www.reversed-java.com/fernflower/, see my comparison on github.com /vorburger/ScratchApplet
有关信息，JD 支持 switch(enum)、switch(string)、assert 语句和 for-each 循环。
关于-g(javac)选项，
不重建原始流程
说明：循环的类型可以
不是确定的，复数
分配不能重新生成，并且
用于重新调整源的算法
代码无法工作。
局部变量数据，JD不行，
有时，确定准确的范围
变量。这是有问题的。
For information, JD supports switch(enum), switch(string), assert statements and for-each loops.
About the -g(javac) options,
not reconstruct the original flow of
instructions : the types of loop can
not be determinate, the multiple
assigments can not be regenerate, and
the algorithm used to realign source
code can not work.
local variable data, JD can not,
sometime, determine the exact range
of variables. It's problematic.
好吧，这是我用手机写的，所以请耐心等待。
首先，每个 java 文件代码都在各自的 .class 文件中编译为字节码。这意味着常量按原样存储（因此可以轻松检索字符串），并将变量分配给寄存器，然后在 JVM 处理类文件时将其放入堆栈程序执行中。
您的异常块未返回到您编写的原始代码的原因是 javac 编译和编译的方式。将代码翻译成java字节码。
如果您想知道哪种反编译器效果最好，请使用一些表达式和表达式编写所有 Java 众所周知的语句（for 循环、if 语句、while 循环）。查看最能代表您的原始代码的内容。
祝你好运。
Ok, this is written from my mobile phone so bear with me.
1st of all, every java file codes are compiled in bytecode in their respective .class file. This means that constants are stored
AS IS(hence strings can easily be retrieved) and variables are assigned to a register that is then put on a stack program execution when the JVM process the class file.The reason your exception block are not returned to the original code you've written is because of the way javac compiled & translated the code to java bytecode.
If you want to know which decompiler works best, write all java well known statements (for loop, if statement, while loop) with some expressions & see what best represent your original code.
Good luck.
自从对该线程的任何反馈以来已经有一段时间了。然而，自从我发现它并认真对待输入后，我觉得提供更新很重要。
我使用 Java Decompiler Free 并取得了很好的成功。然而，最近我不小心删除了一个生产 J2EE 应用程序的相当多的代码。假设 JD Free 可以处理它，但它根本不处理泛型。另外，有一些代码处理变量初始化的方式完全错误。我最终得到的结果是一团糟。
可能没有任何东西可以正确地完成这项工作。就我而言，这只是备份、备份、备份的又一课。我需要一个能够正确处理泛型的反编译器，以便进行批量恢复。但处理变量的一些准确性也会有所帮助。要求一个工具把原代码吐出来就太过分了。但到目前为止我所看到的可以编译，但不能正常运行，除了泛型之外。所以我想圣诞节前还有漫长的一周！！
It's been a while since any feedback to this thread. However since I found it and took the input seriously I feel it important to give an update.
I have used Java Decompiler Free with good success. However, recently I accidentally deleted quite a bit of code of a production J2EE application. assumed JD Free would handle it, but it doesn't handle generics at all. Plus there was code where it handled variable initialization totally wrong. What I ended up with was a total mess.
There may not be anything out there that will to the job correctly. In my case it's just another lesson in backup, backup, backup. I need a de-compiler that handles generics properly in order to do a mass recovery. But some accuracy of handling variables would also help. It is too much to ask a tool to spit out the original code. But what I have seen so far will compile but will not function properly, generics aside. So I suppose it's going to be a long week before Christmas!!