A great tool for digging into obscure jar and class files. I used it many times to track down very obscure bugs in Java based products. Often you will have a vendor saying that your issue is not real or not reproducible on their end. But with this kind of tool you can peek behind the curtains and figure out how to trigger some condition 100% of the time.
I wanted to suggest Fernflower. I have a lot of experience with it, because it's what Jetbrains uses in Intellij. I have only seen it generate sensible code.
I took a quick peek at Vineflower first, and it's a fork of Fernflower. So would recommend that for anyone who might stumble on this in the future who is looking for a decompiler.
if you want to an online java decompiler for a quick analysis, I recommend https://slicer.run/, it has a sleek UI and provides support for a variety of decompilers (including the likes of Vineflower, CFR, JASM, Procyon). For more in-depth analysis, https://github.com/Col-E/Recaf is probably my first choice
Sadly it's not maintained anymore and even the intellijidea-derived decompilers are better nowadays (used to be horrible until a few years ago).
In addition to the limitation to classfiles built for Java8, it sadly has a hard time decompiling new language features even if compiled for a Java8 target. And then there is the well known bug that decompiling full jars in bulk does not get you the same output you see in the UI but orders of magnitude worse... jd was great until it lasted, helped me solve a lot of issues with verdors over the years.
I think this is popping up in Hacker News because the concept of decompilers has become a bit more acceptable recently. (strokes beard)Time was, decompilation was said to be Impossible (as my wise friend syke said: most things people say are impossible are just tedious). Then, it just became "something you could only do in a targeted, single-application fashion.)
Somewhere in there, Alan Kaye laughed and handed everyone dynamic code.
These days, with AI in tow, decompilation is becoming the sort of thing that could be in the toolchain, replacing IDA and such. Why debug and examine when you can literally decompile?!
So, maybe, that idea being considered to be newly on the table, someone felt the need to post a counter-point, proving once again that everything old is new again.
Hats off for decomiling Java apps that mostly predate generics and annotations... both of which were added in 5.
There is a maintained fork of this called jd-gui-duo which includes more features and more decompilers (JADX, Vineflower, Fernflower, CFR, Procyon, ...)
14 comments
[ 3.1 ms ] story [ 42.0 ms ] threadI took a quick peek at Vineflower first, and it's a fork of Fernflower. So would recommend that for anyone who might stumble on this in the future who is looking for a decompiler.
In addition to the limitation to classfiles built for Java8, it sadly has a hard time decompiling new language features even if compiled for a Java8 target. And then there is the well known bug that decompiling full jars in bulk does not get you the same output you see in the UI but orders of magnitude worse... jd was great until it lasted, helped me solve a lot of issues with verdors over the years.
Somewhere in there, Alan Kaye laughed and handed everyone dynamic code.
These days, with AI in tow, decompilation is becoming the sort of thing that could be in the toolchain, replacing IDA and such. Why debug and examine when you can literally decompile?!
So, maybe, that idea being considered to be newly on the table, someone felt the need to post a counter-point, proving once again that everything old is new again.
Hats off for decomiling Java apps that mostly predate generics and annotations... both of which were added in 5.
https://github.com/nbauma109/jd-gui-duo