[HN Gopher] Java Decompiler
___________________________________________________________________
Java Decompiler
Author : mooreds
Score : 116 points
Date : 2025-11-22 17:44 UTC (4 days ago)
(HTM) web link (java-decompiler.github.io)
(TXT) w3m dump (java-decompiler.github.io)
| j16sdiz wrote:
| This one haven't been updated for 5 years and do not support any
| newer java features.
| jbn wrote:
| which new feature are not supported?
| winrid wrote:
| Vineflower is probably what you want nowadays
| mberning wrote:
| 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.
| ternaryoperator wrote:
| It had better be really old Java code. This decompiler supports
| only through Java 8. We're on Java 24 now.
| esafak wrote:
| Java 8 is your everyday corporate code ...
| krzyk wrote:
| Nope, we are on Java 25
| tombert wrote:
| 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.
| PrimeDirective wrote:
| https://github.com/corretto/corretto-8/blob/develop/CHANG
| ELO...
|
| Amazon still supporting Java 8
| drtse4 wrote:
| > Java SE subscribers will receive JDK 8 updates until at
| least December 2030
|
| Not for clients with a commercial license, and there are
| many.
| heelix wrote:
| Oracle is supporting Java 8 till 2030 as a paid binary if
| you download from them and free source code as part of
| the OpenJDK. Other OpenJDK vendors, like Adoptium, are
| providing free binaries till 2030 as well. Other folks
| may or may not provide free binaries. RHEL builds of the
| OpenJKD are free till November 2026, part of extended
| life support till 2030.
|
| For us, the biggest driver for getting off Java 8 was
| SpringBoot dropping support for anything older than 17.
| rileymichael wrote:
| 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.
| bzzzt wrote:
| 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.
| heisenbit wrote:
| 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.
| anta40 wrote:
| What about Android? Hmm....
| uneven9434 wrote:
| 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/).
| embedding-shape wrote:
| Any of these modern choices include features using LLMs to
| further decompile the decompiled code? Seems like an obvious
| direction, even just to infer variable names.
| xxs wrote:
| >Seems like an obvious direction, even just to infer variable
| names.
|
| when debugging symbols are included (sort of the default) the
| local variables are already present; LLM would be the last
| thing I'd consider
| embedding-shape wrote:
| Yeah, I mean duh, of course? Why infer when you have the
| proper names? I don't understand what you're trying to
| point out here...
| webdevver wrote:
| i have no idea why nobody is doing it - it is _such_ an
| obvious use case of LLMs. i guess the reveng market is much
| smaller than most people realized?
|
| then again, who needs reveng when you can use said LLMs to
| write new software "just in time" with the same API.
|
| reveng also was one of those industries that always had a
| very suspicious crowd of people - i dont mean malicious, i
| mean... a lot of them drew a disturbing amount of pleasure
| from doing incredibly labourious work, sort of like someone
| who enjoys putting together an airfix model over many months
| with a microscopic brush and tweezers.
|
| so i wonder if a lot of them perversely _enjoy_ starting at
| reams of bytes and putting together this 10,000 piece puzzle,
| and having an llm solve it for them is a deep affront to
| their tastes.
| m2f2 wrote:
| ... until you realize that the LLM-generated code doesn't
| even compile, or you need a PhD to write all the prompts
| needed to have a prototype instead of the real thing.
| webdevver wrote:
| it doesnt have to be traditional chat interface style.
|
| why doens't someone train an LLM on predicting source
| code given a sequence of input machine code tokens? that
| is so obvious. why does nobody do it?
| croes wrote:
| Not worth the effort
| webdevver wrote:
| youre probably right... for the public market, anyway.
| blackhat state actors would probably not mind having
| something like that. but they'd never talk about it in
| public.
|
| or maybe its not even neccesary, and doing something akin
| to fuzzing syscalls 'but smartly' probably yields more
| results.
| MarkSweep wrote:
| Is it really an obvious use case of LLMs? Traditional byte
| code to source decompilers are faster, use less memory, and
| are deterministic. Using a LLM to decompile code makes as
| much sense as using a LLM to compile code.
|
| That said there are probably ways a LLM could improve a
| decompiler in a way that does not impact its correctness.
| Like deriving class and variables names based on context,
| when symbols are missing or obfuscated.
| m2f2 wrote:
| How do you rate procyon vs these?
| billrobertson42 wrote:
| 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.
| drtse4 wrote:
| 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.
| p0w3n3d wrote:
| 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
| khannn wrote:
| I've only seen that with transient dependencies that are
| instantiated via Reflections
| VonGuard wrote:
| 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.
| darkamaul wrote:
| One of the use case of decompilation 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)
| hhh wrote:
| 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.
| gf000 wrote:
| Do you have a write up of what exactly happened, how
| trivial the vulnerability was?
| never_inline wrote:
| If anything, vulnerability research should be good target for
| AI because failure to find an exploit isn't costly (and
| easily verified) but 1 in N success is very useful.
| branko_d wrote:
| 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).
| leibnitz27 wrote:
| < 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
| Brybry wrote:
| You're awesome! I had really good experiences with CFR in
| the mid 2010s.
|
| I used it for game modding and documentation (and
| caught/reported a few game bugs + vulnerabilities along the
| way). I'd pull game files from Steam depots with steamkit,
| decompile with CFR, and run the resulting java through
| doxygen.
| ynik wrote:
| C# doesn't erase all generics; but there's also some type
| erasure happening: nullable reference types, tuple element
| names, and the object/dynamic distinction are all not
| present in .NET bytecode; these are only stored in
| attributes for public signatures, but are erased for local
| variable types.
|
| C# also has huge amounts of syntactic sugar: `yield return`
| and `await` compile into huge state machines; `fixed`
| statements come with similar problems as "finally" in java
| (including the possibility of exponential code growth
| during decompilation).
| xxs wrote:
| >Generic erasure is a giant pain in the rear
|
| Personally, I don't get the sentiment. Yeah, decompiling
| might not produce the original source code, which is fair.
| It's possible to generate code using invokeDynamic and what
| not - still being valid code if a compiler opts to do so.
|
| When decomiling bytecode there has to be a reason for, and
| a good one. There has to be a goal.
|
| If the code is somewhat humanly understandable that's ok.
| if it's more readable than just bytecode, that's already an
| improvement.
|
| Reading bytecode alone is not hard when it comes to reverse
| engineering. Java already comes with methods and fields
| available by design. Having local variable names and line
| numbers preserved is very common, due to exception stack
| traces being an excellent debugging tool. Hence debugging
| info gets to be preserved.
|
| try/finally shares the same issues, albeit less pronounced.
| misiek08 wrote:
| My personal experience with both is that decompilers work
| great for easy code. I still have both Java and C# projects
| that I wish I decompiled even to worst possible, but almost
| compilable code. Instead getting just decompiler errors or
| code where all variables got the same letter/name and of
| course different types...
|
| I think I've tried all available free tools and some paid in
| Java case. Finally I just deducted logic and reverse
| engineered the most important path.
| malfist wrote:
| I'm not sure you lived the same history I did. Decompiling for
| intermediate languages has always been a thing. Hell, back in
| college as an intern I was looking at the assembly of a
| decompiled C# binary, and back in highschool using intellij's
| Java decompiler to poke at some game applets to see if there we
| hacking opportunities. This was back when ruinscape didn't have
| a paid version
| xxs wrote:
| >Hats off for decomiling Java apps that mostly predate generics
| and annotations... both of which were added in 5.
|
| the 1st very famous and good decompiler was written in C. Other
| than that generics and annotation didn't not make the work
| easier at all decmopilation wise
| croes wrote:
| Is AI really useful in decompiling or does it just create
| similar code that does the same as the original?
| Igor_Wiwi wrote:
| Or you can use https://jar.tools/ - online java decompiler I
| built some time ago. Runs in your browser
| ur-whale wrote:
| > Runs in your browser
|
| You say it like it's a good thing.
| Igor_Wiwi wrote:
| yes, because you don't need to install anything on your
| machine
| almosthere wrote:
| next, add a feature that does a pass with an llm that makes local
| variable names more realistic and adds comments.
| Sanjay_22_xd wrote:
| What is the use of decompiling, is there any real time use case?
| speed_spread wrote:
| Anytime you have to debug closed source libraries. Or even make
| your own implementation.
| rho4 wrote:
| Or when you're too lazy to hunt down the sources, both for
| internal and external dependencies. Just Ctrl+click the method
| and have a quick look at the decompiled implementation, usually
| good enough.
| raver1975 wrote:
| I wish I could use it to recompile itself
| luzifer42 wrote:
| There is a maintained fork of this called jd-gui-duo which
| includes more features and more decompilers (JADX, Vineflower,
| Fernflower, CFR, Procyon, ...)
|
| https://github.com/nbauma109/jd-gui-duo
___________________________________________________________________
(page generated 2025-11-26 23:01 UTC)