Recaf: A Java Bytecode Editor That Hides the Constant Pool
The modern Java bytecode editor
At a glance
- What is it?
- Recaf is an MIT-licensed JavaFX application for editing compiled Java and Android classes at the bytecode level, with built-in decompilers, an assembler, and deobfuscation tooling. The 4.x line is still in alpha, so the practical decision is whether the 2.21 branch or the preview branch fits your work.
- Who is it for?
- Adopt Recaf if you patch or inspect compiled Java and Android classes and want the constant pool, stack frames and wide instruction selection handled for you; the 2.21.14 release from April 2024 is the stable line, while 4.0.0-alpha is a preview. Do not adopt it as a build-pipeline dependency or as an unattended batch tool: the README describes a GUI application, the command line mode is documented as best paired with startup scripts, and no stable 4.x release exists yet.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 4 days ago.
- What is it written in?
- Mainly Java, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Recaf targets: compiled code that no longer matches its source
Reading a class file directly means reading a constant pool, a method table, and a stack map frame table. Editing one means keeping all three consistent, or the JVM rejects the result at verification time. Recaf's README frames the project as an editor that abstracts those details away, listing the constant pool, stack frame calculation, and automatic use of wide instructions as things the editor handles for you. That is the actual product claim. It is not a decompiler with a text box; it is a bytecode workbench where the bookkeeping is done by the tool.
The audience follows from that. Reverse engineers working through obfuscated jars, modders patching behaviour into a compiled artifact, and people auditing third-party dependencies where the source is unavailable or does not match the shipped binary. The README also states support for standard Java and Android applications, which widens the scope beyond plain JVM jars. If your work is source-level refactoring, Recaf is the wrong layer of the stack.
Decompilers, an assembler, and a compiler that all sit on the same model
Recaf does not ship one decompiler. The README describes multiple decompilers that can be switched between, with all of their parameters exposed as configuration. That matters because decompiler output quality varies by code shape, and being able to change engines without changing tools removes a common source of friction.
The assembler is the more distinctive piece. The README states it uses a simple syntax and that you can see the state of local variables and stack values at any point in a method, access variables by name rather than index, and convert snippets of Java source into bytecode sequences automatically. Naming locals instead of tracking slot indices is the difference between readable disassembly and a puzzle. The built-in compiler goes the other direction, recompiling decompiled classes even when some referenced classes are missing. The README qualifies that directly: support may vary depending on code complexity and obfuscation. Treat that sentence as the honest boundary of the feature.
Search is content-oriented rather than text-oriented: strings and numeric constants, class and member references, and instruction patterns. Instruction-pattern search is what you reach for when you know a construct's shape but not its name after obfuscation.
Deobfuscation is treated as a first-class workflow, not an add-on
The README is unusually specific here. Class files crafted to crash reverse engineering tools are patched automatically when opened in Recaf. Jar and zip files are read the way the JVM reads them, which the README says bypasses tricks that cause other tools to display the wrong data. Those two behaviours address a failure mode that is easy to underestimate: a tool that silently shows you incorrect content is worse than one that fails loudly.
On top of that, Recaf supports automatic renaming of obfuscated classes and members, manual renaming, and exporting those mappings to a variety of mapping formats for use in other tools. The export path is the part that keeps you from being locked in. Bytecode transformers for simplifying common obfuscation strategies are also listed, though the README does not enumerate them, so the specifics have to come from the user documentation.
There is also process attachment with instrumentation capabilities, which moves Recaf from static inspection toward runtime observation. The README does not describe the mechanism, so I cannot say how it interacts with a JVM's attach restrictions or with a target running under a security manager.
Getting it running: launcher, gradle build, and the two branches
The README points at a separate launcher repository for downloads and instructions, and notes that independent releases exist but that there are none for 4X currently. Snapshot releases are produced by CI actions. That split is the first thing to understand: the 4.x preview is distributed differently from the 2.x line.
For a source build, the README gives two paths. Clone with git clone https://github.com/Col-E/Recaf.git, then either import the project from build.gradle in an IDE and create a run configuration with the main class software.coley.recaf.Main, or run gradlew build without an IDE. The build output is placed at recaf-ui/build/libs/recaf-ui-{VERSION}-all.jar. There is no separate install step described.
Recaf also runs as a command line application. The README says launch arguments can be listed by passing --help as an application argument, and notes that command line mode is especially useful when paired with scripts provided at startup. That is the whole of the CLI documentation in the README; the argument set itself is not reproduced there.
The version situation is the real adoption risk
The release list tells a story the feature list does not. 4.0.0-alpha is dated 2025-08-31 and is labelled Alpha / Preview. The most recent stable-looking release, 2.21.14, is from 2024-04-27, and the one before it, 2.21.13, is from 2022-03-29. So the stable line has moved slowly, and the branch with the modern UI shown in the repository screenshot is the one still marked preview. The README's own download section confirms there are no independent releases for 4X currently, which means anyone on 4.x is on a snapshot or a self-built jar.
That is a genuine limitation, not a footnote. An alpha bytecode editor can corrupt output in ways that are hard to attribute, and the failure mode is a class file that fails verification much later in your process. If you are editing artifacts you intend to ship, the conservative choice is the 2.21 line until 4.x leaves alpha. If you are exploring, the snapshot path is fine.
The second limitation is scope. The README describes a JavaFX application with a graphical interface, scripting, and plugins. The command line exists, but the README frames it around startup scripts rather than as a batch-processing interface. Anyone hoping to wire Recaf into a CI job that rewrites a hundred jars headlessly should verify that the CLI supports it before assuming so.
Where Recaf sits next to javap and ASM
The honest comparison is not another GUI editor. It is the two things people already use for this work: javap, which ships with the JDK and disassembles a class to text, and ASM, the bytecode manipulation library that Recaf itself lists as a topic and uses for editing.
javap is read-only. You get a disassembly and nothing else; there is no editing model, no stack frame recalculation, no renaming. It is also always available with no install. ASM is the opposite: a library, not an application, and it gives you full control at the cost of writing Java code that constructs and rewrites instruction lists yourself. Stack frame handling in ASM is something you opt into rather than something done for you.
Recaf occupies the middle. It is a program with a UI, not a library you import, and the README's central claim is that it removes the parts of ASM-level work that are tedious rather than interesting. That is a real niche. It is also a narrower one than a library, because automation has to go through Recaf's scripting and plugin APIs rather than through direct calls to a bytecode library in your own build.
Extending it, and what that costs you over time
The README states that almost all functionality is exposed through modular APIs, that automation can be done with scripts, and that plugins can register hooks in APIs that offer them. The developer documentation is hosted separately, with a plugins and scripts section called out by name. So the extension surface is deliberate rather than incidental.
The maintenance implication is that scripts and plugins written against 4.x APIs are tied to an alpha. When the API changes before a stable release, your automation changes with it. That is a cost you accept knowingly or not at all. If you only use the GUI, the cost is lower: you track the launcher and update when a release appears.
The licence is MIT, which is permissive and places few obligations on how you redistribute or modify the software. It also means there is no warranty and no support commitment attached to the code. This is a description of the licence text, not legal advice; if you are redistributing Recaf inside a commercial product, have someone qualified read the licence and the notices of any bundled decompilers, since the README does not enumerate which decompilers ship or under what terms.
Editorial conclusion
Adopt Recaf if you patch or inspect compiled Java and Android classes and want the constant pool, stack frames and wide instruction selection handled for you; the 2.21.14 release from April 2024 is the stable line, while 4.0.0-alpha is a preview. Do not adopt it as a build-pipeline dependency or as an unattended batch tool: the README describes a GUI application, the command line mode is documented as best paired with startup scripts, and no stable 4.x release exists yet. Before committing, verify three things yourself: that your target class files open without transformer errors, that the decompiler you intend to use round-trips through the built-in compiler for your code, and which branch your team will track given that 2.21.14 and 4.0.0-alpha are separate lines.
Community notes