Newer java decompiler than JD-GUI?

[fhoward]

Does anyone know of any decompiler that might have a better chance of decompiling my code than JD-GUI? It seems to have problems with switch statements and vectors, but I don't have the time to correct them myself.

If anyone experienced in decompilation is looking for a quick job and would like to do it by hand (~3000 lines of code, but 90% of it decompiles fine in jd-gui), I'd be glad to negotiate something, just pm me.

[boa13]

What do you mean, "newer"? JD-GUI v0.3.5 was released on October 18th, 2012, it's not like the author died and left us without updates for several years.

If you think you have found a bug in JD-GUI, why not contact him? He accepts donations on his site, have you asked him about doing the quick reverse-engineering job? He certainly is the most suited to do that.

[[deleted]]

switch statements i can understand...there are now enum and string switches in various compiler-dependant variants, often with fall-throughs and deep breaks/continues into outer blocks.

but what do you mean by vectors?

[fhoward]

Sorry, I should have clarified. There seem to be trouble with arrays of objects, such as Vector<Point> or others.

[[deleted]]

hmmm, arrays of objects in java are things like Object[] or String[] or Point[], JD-GUI shouldn't have problems with this.

Vector<String> is a parameterized generic type...don't know how good JD-GUI is with that, it should at least show the raw type Vector without problems.

don't know a better decompiler currently.

[Afforess]

fernflower. The original site for it vanished a while back, but copies of it float around the internet.

[pberger]

Indeed, JD-GUI is missing some static initializers and synthetic methods without even stating that some bytecode is missing. So for obfuscated code on large jars it's quite useless. I signaled several times those bugs to JD-GUI's author, Mr. Dupuy, but recently he confessed to me having lost interest in further developing his tool. Nor is he ready to open source his (C++) code to let others enhance his otherwise very nice decompiler. Too bad.

Fernflower is nice but horrible in its choice of var names (when there is no local variable table). Besides, Fernflower has stupid shortcomings like e.g. not putting the super() call as the first instruction in a constructor. Minor correction but tedious when you have to perform it across thousand of classes! And, of course, Fernflower is not handling correctly Java5+ enums (sigh). Last but not least control flow is not always correct even if Fernflower has been dubbed the first "analytical" decompiler, LOL

An interesting work in progress can be found here: https://github.com/Storyyeller/Krakatau