JD-GUI

JD-GUI shows the source code hidden inside compiled Java programs. Drop a JAR file onto its window and the packages inside unfold as a tree on the left, each class listed beneath its package. Click a class and the right pane fills with reconstructed Java source, colour-coded, with the methods and fields laid out as the original author wrote them, or close enough to read.

The compiled bytecode that Java produces keeps far more structure than a native executable, and this program turns that structure back into something a programmer recognises in a second, without a build system, a project or a command line.

It is a reading tool rather than a recovery tool. The output is an approximation, good enough to understand what a library does, to find where an error in a stack trace came from or to check what a dependency actually calls, and rarely good enough to compile unchanged.

JD-GUI opens CLASS, JAR, WAR, EAR, AAR, KAR, JMOD and ZIP files, runs on the Java runtime already present on a development machine, and has not been maintained for some time, which matters for code compiled with the newest language features.

The sections below cover what it reads well, how to move around a large archive and where it falls down.

Opening an archive and reading the tree

Open a file in JD-GUI from the menu, from the recent list or by dragging it in, and the left pane shows the archive’s contents as a package hierarchy, with nested archives inside an application file opened in place. Classes are listed with their inner classes beneath them, and resource files such as manifests and properties sit alongside the code, the same files 7-Zip shows when it opens the JAR as the ZIP it is.

Click any class and its decompiled source appears in a tab on the right, with syntax colouring and line numbers that correspond to the original line table where the compiler kept one.

Several classes open as separate tabs, so a method’s callers and callees sit side by side. The source is read-only in the window, and a copy of any selection goes to the clipboard for pasting elsewhere. Tabs keep the structure of a problem visible while a fix is drafted.

Moving around the code

Names in the decompiled source are links. Click a class name, a method or a field that lives in the same archive and the view jumps to its declaration, which is how a call chain is followed across a library without searching. Navigation stops at the archive’s edge, so a reference into another JAR has to be opened separately, and a back button retraces the path.

A search dialog finds types and members, and string constants, across the open archive by name or by pattern, which locates the class that holds a configuration key or the method that produces an error message. The find bar searches within the current source.

Those two together turn a library of several thousand classes into something that answers questions in minutes rather than hours.

Reading a stack trace against the code

Drag a log file onto the JD-GUI window and it reads the stack traces in it, decompiles the classes they name and highlights the exact line each frame points to, so an error reported from production can be read against the code that threw it.

That single feature is why it stays installed on machines that have moved on to other decompilers for everything else. A trace copied from a bug tracker and pasted into a text file works the same way, so the reporter’s log and the library’s code line up on one screen.

Exporting sources and adding extensions

JD-GUI Save All Sources writes every decompiled class in the archive to a ZIP of .java files, for searching with other tools or for reading in a code editor with proper syntax support. A single class saves on its own.

The program is extensible by placing additional modules on its classpath at launch, which is how alternative decompiling engines and extra file types have been bolted on by people who needed them.

Where it falls down

The JD-GUI decompiling engine is frozen at the language features it knew. Code compiled with the newer constructs, text blocks, records, sealed classes and the latest switch forms, produces output that is wrong, incomplete or missing entirely, and lambda expressions trip older builds.

For current bytecode, a maintained decompiler produces far better source, and this program is best kept for older libraries and for its stack trace feature. Obfuscated code decompiles into renamed classes and scrambled control flow that no tool reads easily, and this one makes no special effort.

It needs a Java runtime installed, which is no burden on a development machine and an extra step on any other. Decompiling someone else’s code also has limits beyond the technical ones, since licences and terms often forbid it, and the tool is for understanding what you are entitled to understand. Reading a library you depend on to diagnose a failure sits comfortably inside that line, and redistributing what you reconstruct does not.

Conclusion

JD-GUI suits programmers who need to look inside a compiled library quickly, from checking what a dependency does to reading the line a production error came from, and who want that with a double-click rather than a build. The package tree, the clickable navigation and the stack trace mapping remain the fastest way to answer those questions on older code.

It is the wrong tool for bytecode compiled with recent language features, where its output cannot be trusted, and for anything obfuscated. Keep it for older libraries and for stack traces, use a maintained decompiler for the rest, and remember that reading someone’s code is bounded by what their licence allows.