Recaf: a Java bytecode editor that hides the constant pool

What Recaf solves, and who actually needs it

Editing compiled Java is normally a fight with the class file format. A single method body carries a constant pool, a stack map table, local variable tables, and instruction widths that change when an operand no longer fits. Recaf's stated goal is to abstract those details away. The README lists the constant pool, stack frame calculation, and the use of wide instructions among the things the editor handles for you.

The audience is narrow and specific. Someone auditing a third party jar, recovering logic from an obfuscated application, or patching a class without the original source will get value immediately. Android is covered too, since the README claims support for standard Java and Android applications. A developer who simply wants to read decompiled code once is better served by a plain decompiler, because Recaf's editing surface is the point, not the decompilation.

How the editor, assembler and decompilers fit together

Recaf is a JavaFX desktop application split across modules in the repository: recaf-core holds the model and services, recaf-ui holds the interface, and libs holds supporting code. The README describes the application as exposing almost all of its functionality through modular APIs, which is how scripts and plugins reach the same internals the UI uses.

The editing model works at two levels. A high level view decompiles a class so you can read it as Java, and a low level view presents bytecode through Recaf's own assembler syntax. That assembler is not a thin disassembly dump. The README says it shows the state of local variables and stack values at any point in a method, lets you access variables by name rather than index, and can convert snippets of Java source into bytecode sequences. Multiple decompilers are supported and their parameters are configurable, so the same class can be read through different engines when one produces nonsense.

Around that core sit the deobfuscation tools. Class files crafted to crash reverse engineering tools are patched when opened, and jar or zip files are read the way the JVM reads them, which the README frames as a defence against archives that trick tools into showing the wrong data. Renaming of obfuscated classes and members can be automatic or manual, and the resulting mappings can be exported to several mapping formats for use elsewhere. There is also an attach mode for running Java processes with instrumentation.

Installing Recaf and editing your first class

The README does not publish a package manager command. It points to the Recaf-Launcher repository for downloads and usage instructions, and notes that snapshot releases are available through the project's CI actions. Independent releases for 4X are listed as none currently.

If you prefer to build from source, the README gives these steps. The output lands in the recaf-ui module:

git clone https://github.com/Col-E/Recaf.git
./gradlew build

After the build, the README states the artifact is at recaf-ui/build/libs/recaf-ui-{VERSION}-all.jar. Running that jar opens the JavaFX interface. For IDE work the README says to import from build.gradle and create a run configuration with the main class software.coley.recaf.Main.

Once the window is open, the normal first move is to load a jar or class file, pick a class in the navigator, and switch between the decompiled view and the assembler view. Recaf also runs as a command line application, which the README suggests pairing with scripts provided at startup; passing --help as an application argument lists the current launch arguments.

The built-in compiler is the weakest link

Recaf can decompile a class, let you edit the Java, and compile it back. The README qualifies this heavily: the compiler works when supported, and support may vary depending on code complexity and obfuscation. That is the honest version of a hard problem. Decompiled output is not the original source, and a compiler fed reconstructed source will fail on anything the decompiler guessed wrong.

So the practical rule is that the assembler path is the reliable one. If you need a guaranteed edit, work in the bytecode view where you control the instructions directly. Treat the Java-level recompile as a convenience for simple, unobfuscated classes, and expect to fall back when it refuses.

The other limitation is release maturity. The most recent release listed is 4.0.0-alpha from 2025-08-31, and the README points 4X users at the launcher and CI snapshots rather than a stable download. The last push to the repository was on 2026-09-09, so work is ongoing, but an alpha label means interfaces and behaviour can move under you.

Recaf compared with plain disassembly tools

The obvious alternative for bytecode work is javap, shipped with the JDK. javap prints a disassembly and stops there. It has no editor, no constant pool rewriting, no stack map recalculation, and no rename mappings. Its advantage is that it is always present, always the same version as your JDK, and produces output you can diff in a terminal.

Recaf's difference is that it owns the whole loop: open, inspect, patch, reassemble, export mappings. That matters when the task is a jar full of obfuscated classes, where a text disassembly leaves you to track constant pool indices by hand. It matters less when you only need to confirm which method a stack trace points at, and in that case javap is faster because there is nothing to launch.

A second reference point is the decompiler ecosystem Recaf wraps rather than replaces. Recaf lets you switch between multiple decompilers and configure their parameters, which is useful precisely because no single decompiler handles every class. Using one of those decompilers standalone gives you the same reading experience without the editing layer.

Licence, upgrades and the cost of tracking an alpha

Recaf is MIT licensed, which is permissive and places few obligations on anyone embedding or redistributing it. The repository ships a LICENSE file at the top level. As always, the licence text governs, not a summary.

The upgrade story is the part to plan for. Because 4X has no independent releases, the README directs users to the launcher and to CI build artifacts, which means the version you run is tied to a build pipeline rather than a numbered download. The 2.21 line has independent releases, the most recent listed being 2.21.14 from 2024-04-27, but that is a different generation of the application. Anyone standardising on Recaf should decide early whether they are pinning a snapshot or waiting, and should record which snapshot they built against, since a rebuild later may not reproduce the same jar.

Automating Recaf through scripts and plugins

The scripting and plugin surface is where Recaf separates itself from a GUI-only tool. The README states that almost all functionality is exposed through modular APIs, that scripts handle automation, and that plugins can register hooks in APIs that offer them. Developer documentation lives at recaf.coley.software under the plugins and scripts section.

Combined with the command line mode, this opens a batch path: launch Recaf with a script at startup, have the script walk a set of classes, apply a bytecode transformer, and export rename mappings. The README mentions bytecode transformers for simplifying common obfuscation strategies, and mapping export in a variety of formats, which is the piece that lets Recaf feed other tools in a pipeline rather than being the final destination.

What the README does not document is a stable API versioning guarantee. Plugins hook into internal APIs, and the project is on an alpha line, so a plugin written today may need changes after an upgrade. Keep plugin code small and isolated from anything you cannot rebuild.

Editorial conclusion

Recaf fits engineers who edit class files by hand, deobfuscate jars, or need to inspect bytecode without memorising the constant pool format. It does not fit anyone who needs a stable, versioned toolchain: the 4.0 line is published as an alpha, the last independent releases listed are from the 2.21 line, and the README states that independent releases for 4X do not currently exist. Before adopting it, open the user documentation at recaf.coley.software, check whether the launcher's snapshot build matches the release you intend to use, and test the built-in compiler against one of your own obfuscated classes, because the README itself warns that recompilation support varies with code complexity.

Frequently asked questions

Official sources

1. Col-E/Recaf on GitHub
2. License: MIT
3. Project website
4. README
5. Releases