Java Decompiler
67 points
3 days ago
| 9 comments
| java-decompiler.github.io
| HN
uneven9434
3 hours ago
[-]
More modern choices are JADX (https://github.com/skylot/jadx) or Vineflower (https://github.com/Vineflower/vineflower). If you want a paid, higher-quality option, try JEB (https://www.pnfsoftware.com/).
reply
drtse4
2 hours ago
[-]
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.

reply
p0w3n3d
20 minutes ago
[-]
The most annoying thing in intellij (fernflower is it) is that it does not maintain correct line numbers, so when debugging, there is a divergence. Still you need to download sources but not always they are available
reply
VonGuard
2 hours ago
[-]
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.

reply
branko_d
1 hour ago
[-]
Is there anything especially hard about decompiling (to) Java?

.NET/C# decompilers are widespread and generally work well (there is one built into Visual Studio nowdays, JetBrains have their own, there were a bunch of stand-alone tools too back in the the day).

reply
leibnitz27
41 minutes ago
[-]
< disclaimer - I wrote CFR, which is one of the original set of 'modern' java decompilers >

Generic erasure is a giant pain in the rear. C# doesn't do this. You don't actually keep any information about generics in the bytecode, however some of the metadata is present. BUT IT COULD BE FULL OF LIES.

There's also a huge amount of syntactic sugar in later java versions - take for example switch expressions.

https://www.benf.org/other/cfr/switch_expressions.html

and OH MY GOD FINALLY

https://www.benf.org/other/cfr/finally.html

reply
darkamaul
2 hours ago
[-]
One of the use case of décompilation is bug hunting / vulnerability research. And that’s still one of the use cases where AI isn’t that good because you must be precise.

I’m not saying that won’t change but I still see a bright future for reversing tools, with or without AI sidekicks (like the BN plugin)

reply
hhh
1 hour ago
[-]
I used codex 5.1 yesterday to point at a firmware blob and let it extract and explore it targeting a specific undisclosed vulnerability and it managed (after floundering for a bit) to read the Lua bytecode and identify and exploit the vuln on a device running the firmware.
reply
Sanjay_22_xd
12 minutes ago
[-]
What is the use of decompiling, is there any real time use case?
reply
Igor_Wiwi
1 hour ago
[-]
Or you can use https://jar.tools/ - online java decompiler I built some time ago. Runs in your browser
reply
ur-whale
1 hour ago
[-]
> Runs in your browser

You say it like it's a good thing.

reply
Igor_Wiwi
58 minutes ago
[-]
yes, because you don't need to install anything on your machine
reply
winrid
5 hours ago
[-]
Vineflower is probably what you want nowadays
reply
j16sdiz
5 hours ago
[-]
This one haven't been updated for 5 years and do not support any newer java features.
reply
jbn
48 minutes ago
[-]
which new feature are not supported?
reply
almosthere
52 minutes ago
[-]
next, add a feature that does a pass with an llm that makes local variable names more realistic and adds comments.
reply
mberning
5 hours ago
[-]
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.
reply
ternaryoperator
4 hours ago
[-]
It had better be really old Java code. This decompiler supports only through Java 8. We're on Java 24 now.
reply
esafak
4 hours ago
[-]
Java 8 is your everyday corporate code ...
reply
tombert
3 hours ago
[-]
Didn't Oracle drop support for Java 8 like six years ago? I'm sure there are plenty of companies still running it, but even Apple (a relatively conservative company in this regard) updated to Java 11 when I was there in ~2019.
reply
drtse4
2 hours ago
[-]
> Java SE subscribers will receive JDK 8 updates until at least December 2030

Not for clients with a commercial license, and there are many.

reply
PrimeDirective
3 hours ago
[-]
reply
rileymichael
2 hours ago
[-]
this isn't really the case. a lot of legacy code may still be running the version it was developed against, but java 17+ has a sizable share of the ecosystem now that all of the popular libraries require it. spring for example bumped their baseline to jdk 17 in 2022.
reply
bzzzt
26 minutes ago
[-]
Doesn't really matter if you're using an old Spring version with the old Java version. Spring offers enterprise support for Spring framework 5 which still supports Java 8.

But organizations still using Java 8 will most likely use some kind of Java Enterprise application server with vendor support. IBM will support Websphere with Java 8 until at least 2030 and maybe longer if customers keep paying. I'd guess Oracle has a similar policy.

reply
heisenbit
2 hours ago
[-]
It used to but Oracle‘s licensing and probably more important security guidelines from the very top linking CVE scores to mandatory updates got things moving on the last years.
reply
krzyk
3 hours ago
[-]
Nope, we are on Java 25
reply