Skip to content

Java Decompiler

Jump to bottom
Mike Strobel edited this page Oct 27, 2019 · 4 revisions

As a developer who splits his time between the .NET and Java platforms, I have been surprised and dismayed by the lackluster selection of decompilers in the Java ecosystem. Jad (no longer maintained, closed source) and JD-GUI (GPL3) are pretty decent choices, but the former does not support Java 5+ language features, and the latter tends to barf on code emitted by my LINQ/DLR tree compiler.

To address the situation, I recently started developing a decompiler myself, inspired by (and borrowed heavily from) ILSpy and Mono.Cecil.

Status

While still incomplete, my own tests seem to indicate that the Procyon decompiler can generally hold its own against the other leading Java decompilers out there. There are, however, some known issues.

Known Issues

  1. Classes compiled with Eclipse (or anything other than javac) may produce less than optimal results, especially for constructs like String-based switch statements. Up until now, I have mostly tested classes compiled with Javac. I will work to improve support for other compilers as time goes on.

Why should I care?

The Procyon decompiler handles language enhancements from Java 5 and beyond that most other decompilers don't. It also excels in areas where others fall short. Procyon in particular does well with:

  1. Enum declarations
  2. Enum and String switch statements (only tested against javac 1.7 so far)
  3. Local classes (both anonymous and named)
  4. Annotations
  5. Java 8 Lambdas and method references (i.e., the :: operator).

Output Comparison

I've posted some simple Decompiler Output Comparison comparing original source, decompiled output, and JD-GUI output.

How to Use

Java 7 is required to run. Unfortunately, I do not yet have a slick GUI front-end like JD-GUI (but third-party front-ends do exist--see below!). I do, however, offer color-coded output for consoles supporting ANSI/xterm-256. I also offer three output modes:

  1. Java (default)
  2. Raw Bytecode (similar to javap, but prettier; run with -r)
  3. Bytecode AST (an intermediate representation; run with -b, add -u for unoptimized)

Note that color-coded output requires an ANSI-compatible console. Unfortunately, this rules out the Windows command prompt. To get color-coded output on Windows, I recommend using a terminal environment like MobaXterm. If ANSI detection fails for whatever reason (as it does with MobaXterm), you can force it on by running with -DAnsi=true.

The main class (entry point) is com.strobel.decompiler.DecompilerDriver. It's also the entry class for decompiler.jar (available under Downloads). You can pass in one or more types to be processed. At the moment, all output goes to System.out. I will probably add file-based output in the future. To call the public API externally, use the helper class com.strobel.decompiler.Decompiler.

The input types can be fully-qualified names in dotted or binary form (e.g., java.lang.String or java/lang/String) or relative/absolute file paths (path/to/MyClass.class or C:\src\path\to\MyClass.class) or even whole jar files. If you pass in a type name, it will attempt to load it out of the user or bootstrap classpath. If you have trouble getting it to locate classes from jars or directories in your CLASSPATH environment variable, try running the main class directly instead of running with -jar.

I still have a remarkably flimsy grasp of how all this classpath business works in Java, so if someone would like to educate me (or submit a pull request), be my guest :).

Usage Examples

Assuming that you have renamed the download file from procyon-decompiler-x.x.xx.jar to decompiler.jar, the following are some common options.

Show help/usage information and exit.

:::bash
$ java -jar decompiler.jar
$ java -jar decompiler.jar -?

Decompile a single class to the console.

:::bash
$ java -jar decompiler.jar java.lang.String
$ java -DAnsi=true -jar decompiler.jar java.util.Collections

Decompile a whole jar to a directory.

:::bash
$ java -jar decompiler.jar -jar myJar.jar -o out

Decompiler API

The command-line decompiler is simply a front-end; the decompiler itself is a framework that can be integrated into other applications and called programmatically. To learn more, read this.

GUI Front Ends

Don't want to use the command line? Try one of these GUI front-ends for Procyon:

  • SecureTeam Java Decompiler
    A JavaFX-based decompiler front-end with fast and convenient code navigation. Download it, or launch it directly from your browser.

  • Luyten
    An open source front-end by deathmarine.

  • Bytecode Viewer is an open source Java decompilation, disassembly, and debugging suite by @Konloch. It can produce decompiled sources from several modern Java decompilers, including Procyon, CFR, and FernFlower.

  • Helios is similar to Bytecode Viewer. But is a completely new and independent project, which uses SWT instead of Swing.

Send me your feedback!

If you are using my decompiler, I would love to hear from you. Drop me a line (email / twitter) and tell me about your experiences--did it work or not work? Did you love it or hate it?

Alternatives

There are other Java Decompiler projects underway that you should check out:

  • CFR by Lee Benfield is well on its way to becoming the premier Java Decompiler. Lee and I actually work for the same company and share regression tests. We're engaged in a friendly competition to see who can deliver a better decompiler. Based on his progress thus far, there's a very good chance he will win--at least on decompiling obfuscated code :).
  • Krakatau by Robert Grosse, written in Python, includes a robust verifier. It focuses on translating arbitrary bytecode into valid Java code, as opposed to reconstructing the original code.
  • Candle by Brad Davis, developer of JBoss Cake, is an early but promising work in progress.
  • Fernflower an analytical Java decompiler.
  • JD GUI is an Decompiler, which comes with its own GUI. All is licensed under GPLv3. Like CFR the source for the decompiler itself, is not published, but you have the right to decompile the bionaries. And the binaries are under an OpenSource-License (CFR is under the MIT-license and JD Core is under the GPLv3 license)
Clone this wiki locally