JarEditor edits the contents of a jar from inside the IDE, without unpacking it

The jar appears as a project, not as an archive

JarEditor is an IDEA plugin for modifying files in a jar directly without decompression, including class and resource files, and the way it achieves that is by making the archive behave like a project inside the IDE.

The plugin lives on the JetBrains marketplace as JarEditor, with a separate download counter badge, and the SDK badge in the README says IDEA 2020.3. The README also notes that this is a JetBrains plugin, and that VS Code users can install an equivalent from the VS Code Extensions Marketplace, with the source at a separate repository, jar-editor-vscode. So there are two implementations of the same idea, and the IntelliJ one is the more mature of the two given the release history, with v2.2 in November 2024, v2.3 in May 2025 and v3.0 in February 2026. The last push to this repository was on 2026-08-23.

The interaction model is short. After installation you see a tab page to switch to the Jar Editor in the decompiled class file. For an external jar, you add it through File, then Project Structure, then Libraries and Add Library, and the decompiled jar becomes visible. For a nested jar, you right click it and choose JarEditor, then Structure, then Expand Nested Jar. There is also a newer shortcut, double-clicking a jar or a nested jar file to expand its contents.

The point of all this is that the jar stops being an opaque blob and becomes a set of files you can open in the editor you already use.

Save(Compile) into jar_edit_out, then Build Jar writes it back

The mechanisms section is where the plugin explains what actually happens when you press the buttons, and it is the part worth reading before you rely on it.

After a modification you click Save(Compile) to compile and save the currently modified Java content. Then you click Build Jar to write the compiled and saved class file into the jar package. Modifying the resource files in the jar is supported as well.

Underneath, Save(Compile) writes the modified files to a subdirectory called jar_edit_out in the directory where the jar package is located. Build Jar then incrementally writes the modified files to the jar, and finally deletes that directory.

That is a sensible design for a plugin that has to be safe with your artifacts. Nothing is written into the original archive until you ask for it, and the intermediate state lives next to the jar where you can inspect it. The incremental write also means the unchanged entries of a large archive are not rewritten, which matters for a fat jar.

The compilation itself uses the JDK of your SDK list, and you can choose both the SDK and the target version of the compiled class. The classpath for the compilation is the project's Libraries dependency, and the README explains the fix when a dependency cannot be found, which is to add it under File, Project Structure and Libraries.

In other words, the plugin compiles your patched class against the same dependencies the project already declares, which is the only way the result is going to link at runtime.

Nested jars, Spring Boot archives and the formats it handles

The formats list is short and specific, and it is the list of archives that Java projects actually ship in.

The plugin supports Spring Boot jars, nested jars, war, ear, zip and aar. Spring Boot deserves its own mention because the executable jar format nests the application classes and its dependencies inside the archive, and the nested jar expansion is the feature that makes the plugin useful on a modern Spring Boot build rather than only on a plain library jar.

The aar entry covers Android libraries, and the war and ear entries cover the two older Java EE packaging formats. Kotlin is supported as well, which matters because a large share of Java projects are now written in it and a class file has no memory of which language produced it.

The other half of the format story is the export of a source jar, which lets you take the decompiled sources out of an archive and work on them properly, if you intend to keep the changes.

For the people who do not have the source at all, the plugin also offers a class bytes tool, and that is the section to read when a decompilation looks wrong. For obfuscated jars, the decompilation result is not satisfactory, and the class bytes tools let you work on the bytecode directly instead of fighting the decompiler.

Two bytecode editors for the cases decompilation cannot handle

The class bytes tool section names two options, and they work at different levels.

The first is Javassist, where the README says that fields, methods, constructors and static code can be modified, added or deleted, including inner classes. Javassist works on the Java class file model rather than on raw instructions, which makes structured edits like adding a method comparatively direct.

The second is Visual ClassBytes, described as a class bytecode editor based on ASM and BCEL, with its own repository. ASM is the bytecode library that most Java tooling is built on and BCEL is a class file library, so this is an editor that works at the level of instructions, with a visual front end rather than a text one.

The choice between them is a choice about how much structure you want to keep. Javassist is the higher level option and the natural first try, and the instruction level editor is what you fall back to when the class is obfuscated enough that its structure no longer matches anything a source level editor can represent.

The plugin also bundles a choice of decompilers, listing Fernflower, CFR, Procyon and Jadx. That list is not redundant, because the four produce noticeably different output on the same class, and picking the one that reads best for a given jar is often the difference between a readable patch and an afternoon of reading raw bytes.

Which JDK does the compile use, and the SDK Default table

There is a small table in the README that answers a question that will otherwise cost an hour.

When compiling and selecting SDK Default, the runtime JDK integrated by JetBrains is used, the bundled JBR. If SDK Default is not selected, the JDK installed by the user is used instead. The table maps the IDE version to the bundled runtime, with IDEA 2020.3 through 2022.1 using a JBR JDK 11, IDEA 2022.2 through 2024.1 using a JBR JDK 17, and IDEA 2024.2 and later using a JBR JDK 21.

The consequence is that the class file you produce has a bytecode version determined by the IDE, not by the project, unless you pick an SDK yourself. A project that targets Java 8 and is opened in a 2024.3 IDE will produce classes for a newer runtime unless you select an SDK.

That is the one behaviour of the plugin worth checking before you use it in a build, because a jar containing a class compiled for a newer runtime than the server supports fails at class load time, not at build time, and the error message points at the jar rather than at the tool that wrote it.

The same section is also where the plugin tells you where the classpath comes from, and it is worth knowing that the compilation classpath is the project's Libraries dependency, so an archive you open outside a project has no classpath at all until you add one.

Search, file operations and the VS Code sibling project

The remaining features are the ordinary file manager operations, applied to an archive.

In the project view of the jar package, right clicking gives you JarEditor and then New, Delete and other operations, where you can add, delete, rename, copy, paste, export and back up files. The Search icon searches the contents of the jar package, and for a class jar the search runs on the decompiled content, which is a detail with real consequences. A search that matches on decompiled source will find a method that exists in the bytecode, and it may also match a string that the decompiler reconstructed differently from the original.

Copying and pasting files to and from the clipboard is supported, which is a small thing until you have tried to move a resource file out of a signed archive by hand.

The VS Code situation is worth a note for anyone choosing between the two. The README says this project is a JetBrains plugin, and that VS Code users can install it from the VS Code Extensions Marketplace, with details on a separate repository, jar-editor-vscode. The IntelliJ plugin has the longer release history here, and the VS Code build is a separate codebase with its own pace, so treat them as two projects with one idea.

The repository itself is a Gradle project with build.gradle.kts, settings.gradle.kts, a gradle.properties, the src/ directory with the plugin code, an img/ directory with the screenshots the README embeds, a Chinese README, and a count_lines.sh script.

Where JarEditor is the wrong tool

Three situations rule it out.

The first is when you have the source. If the jar was built from a repository you can clone, a rebuild is faster, produces a jar that matches the build byte for byte, and does not leave you editing decompiled code that may not round trip. The plugin is for the case where the source is not available, not for the case where rebuilding is merely inconvenient.

The second is a signed or checksummed artifact. The plugin writes into the jar, so a signature stops matching and a checksum stops matching, and the fix is re-signing, which is a different process from editing a class. For a release artefact, the same change belongs in the build.

The third is a large archive with a nested structure where you need to change many classes at once. The plugin is built around the IDE's file model for the archive contents, and while it handles nested jars, a bulk transformation across a large dependency tree is the kind of job a script over the archive does better.

For a single class in a dependency, a class in a jar you are about to ship, or an obfuscated archive you need to understand, it is the tool that saves the most time, because it puts the decompiler, the compiler and the packager in one window.

Editorial conclusion

JarEditor fits a developer who has to patch a jar they do not have the source for, whether that is a dependency in a build, a Spring Boot archive with a nested jar, or a release where one class needs changing, because the whole loop of decompile, edit, compile and repack happens inside the IDE. It is the wrong tool when you have the source, since a rebuild from source is faster and produces a jar that matches the build, and the wrong tool for a signed or checksummed artifact, since writing into the archive changes it. Before adopting it, check which JDK it will compile against, because the plugin uses the JDK from your SDK list and the JetBrains runtime by default, and remember that a search over a class jar runs against decompiled content, not raw bytes.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. Liubsyy/JarEditor on GitHub
4. README
5. Releases