Introduction

To decompile an entire JAR file, use a command-line decompiler like CFR, Procyon, or Fernflower that can process all .class files in one pass and output Java source files. A JAR is just a ZIP archive containing compiled .class bytecode, resource files, and a manifest. Decompilation reverses the compilation step, producing readable (though not identical) Java source code from the bytecode. This is useful for debugging third-party libraries, understanding legacy code, or auditing dependencies when no source is available.

Decompiler Comparison

Each decompiler handles different Java language features with varying quality. The right choice depends on the Java version of the bytecode you are working with.

Method 1: CFR (Recommended for Modern Java)

CFR is a single JAR file with no dependencies. Download it from the GitHub releases page and run:

1# Decompile entire JAR to a directory
2java -jar cfr-0.152.jar myapp.jar --outputdir ./decompiled
3
4# Decompile with specific options
5java -jar cfr-0.152.jar myapp.jar \
6  --outputdir ./decompiled \
7  --caseinsensitivefs false \
8  --removeboilerplate true \
9  --decodelambdas true

CFR writes one .java file per class, preserving the package directory structure. The output directory will mirror the original package hierarchy:

1decompiled/
2  com/
3    example/
4      Main.java
5      service/
6        UserService.java
7        OrderService.java

Method 2: Procyon

Procyon works similarly to CFR and produces clean output for Java 5 through 8 bytecode:

1# Download procyon-decompiler
2# Decompile entire JAR
3java -jar procyon-decompiler-0.6.0.jar -jar myapp.jar -o ./decompiled
4
5# Decompile a single class from the JAR
6java -jar procyon-decompiler-0.6.0.jar -jar myapp.jar com.example.Main

Procyon is particularly good at reconstructing for-each loops, try-with-resources, and generics from older bytecode.

Method 3: Fernflower (IntelliJ's Decompiler)

Fernflower is the decompiler built into IntelliJ IDEA. You can use it standalone from the command line:

1# Fernflower is bundled with IntelliJ IDEA
2# Find it at: <IntelliJ>/plugins/java-decompiler/lib/java-decompiler.jar
3
4java -cp java-decompiler.jar \
5  org.jetbrains.java.decompiler.main.decompiler.ConsoleDecompiler \
6  -dgs=true myapp.jar ./decompiled

Alternatively, open any JAR directly in IntelliJ IDEA. The IDE decompiles classes on the fly as you navigate through them. To export all decompiled sources, right-click the JAR in the project explorer and select "Decompile to Java."

Method 4: Vineflower (Improved Fernflower Fork)

Vineflower is an actively maintained fork of Fernflower with better output quality:

java -jar vineflower-1.10.1.jar myapp.jar ./decompiled

It handles modern Java features like pattern matching, switch expressions, and text blocks better than the original Fernflower.

Method 5: JD-GUI (Visual Browsing)

JD-GUI is a graphical tool for browsing decompiled code interactively. It is useful for quick inspection rather than batch decompilation:

1. Download JD-GUI from the project website.
2. Open the JAR file (drag-and-drop or File > Open).
3. Browse classes in the tree view on the left.
4. To save all sources: File > Save All Sources. This exports a ZIP file containing the decompiled .java files.

JD-GUI is no longer actively maintained and struggles with Java 13+ features. For modern codebases, use CFR or Vineflower instead.

Shell Script for Batch Decompilation

When you need to decompile multiple JAR files (e.g., all dependencies in a lib/ directory), a simple shell script automates the process:

1#!/bin/bash
2# decompile-all.sh - Decompile all JARs in a directory
3CFR_JAR="cfr-0.152.jar"
4INPUT_DIR="./lib"
5OUTPUT_DIR="./decompiled"
6
7for jar in "$INPUT_DIR"/*.jar; do
8    jar_name=$(basename "$jar" .jar)
9    echo "Decompiling: $jar_name"
10    java -jar "$CFR_JAR" "$jar" --outputdir "$OUTPUT_DIR/$jar_name" 2>/dev/null
11done
12
13echo "Done. Output in $OUTPUT_DIR"

chmod +x decompile-all.sh
./decompile-all.sh

Extracting Without Decompiling

Sometimes you need to inspect the raw contents of a JAR without decompiling the bytecode. Since a JAR is a ZIP file, standard tools work:

1# List contents
2jar tf myapp.jar
3
4# Extract everything
5jar xf myapp.jar
6
7# Extract with standard unzip
8unzip myapp.jar -d extracted/
9
10# View the manifest
11unzip -p myapp.jar META-INF/MANIFEST.MF

To inspect individual .class files at the bytecode level without decompiling to Java:

1# Disassemble a class file to bytecode instructions
2javap -c -p com.example.Main
3
4# Include constant pool and other metadata
5javap -v com.example.Main

javap is included in the JDK. It shows the actual bytecode instructions, which is useful when decompiled Java source does not accurately represent the behavior.

Handling Obfuscated JARs

Many commercial applications run their bytecode through obfuscators like ProGuard, R8, or Zelix KlassMaster. Obfuscated code decompiles but is difficult to read:

1// Obfuscated output example
2public class a {
3    private final b c;
4    
5    public void d(String e) {
6        this.c.f(e, new g(h.i, 42));
7    }
8}

Tips for working with obfuscated code:

• Use CFR with --rename true to get slightly more readable placeholder names.
• Look at string constants and API calls. Obfuscators rarely encrypt string literals.
• Cross-reference with the JAR's META-INF/MANIFEST.MF and any included mapping files (e.g., proguard-mapping.txt).
• Focus on the entry points (main class, servlet classes, Spring components) and trace outward.

Common Pitfalls

Expecting decompiled code to compile directly. Decompilers produce approximations of the original source. Inner classes, synthetic bridge methods, and compiler optimizations can produce code that looks correct but does not compile. Treat the output as a reading aid, not a build artifact.

Using JD-GUI for modern Java bytecode. JD-GUI has not been updated to handle Java 13+ features like text blocks, records, or sealed classes. Use CFR or Vineflower for any bytecode compiled with Java 11 or later.

Ignoring legal implications. Decompiling proprietary software may violate license agreements. Many commercial licenses explicitly prohibit reverse engineering. Check the license terms before decompiling, especially for redistribution.

Not including dependency JARs. Decompilers produce better output when they can resolve referenced classes. If the JAR depends on other libraries, provide them as additional inputs so the decompiler can resolve types correctly. In CFR, use --extraclasspath.

Confusing jar xf with decompilation. Extracting a JAR gives you .class files (bytecode), not .java files (source). You need a decompiler to convert bytecode back to readable Java.

Summary

• Use CFR for modern Java (lambdas, records, sealed classes) with java -jar cfr.jar app.jar --outputdir ./out.
• Use Procyon for clean decompilation of Java 5-8 era code.
• Use Fernflower or Vineflower when working inside IntelliJ IDEA or when structural accuracy matters.
• Use JD-GUI only for quick visual browsing of older bytecode.
• A JAR is just a ZIP file. Use jar tf to list contents and javap -c to inspect bytecode directly.
• Decompiled code is an approximation. Do not expect it to compile without modifications.
• Always check license terms before decompiling proprietary software.