Convert JAR to JAVA

Source files are needed when a JAR is the only available copy of a Java library or application and its code must be inspected, audited, modified, or rebuilt. Most release JARs contain compiled .class files, so recovering .java files usually requires decompilation rather than a direct file conversion.

What a JAR file contains

A JAR (Java Archive) is a ZIP-based archive used by Java developers, build tools, and application vendors to distribute libraries, plugins, and applications. It commonly contains compiled classes, resources, dependency metadata, and META-INF/MANIFEST.MF; executable JARs may declare a startup class in that manifest.

JDK tools, Maven, Gradle, Eclipse, and IntelliJ IDEA can create or consume JARs. A separate archive named name-sources.jar often contains the original source files and should be used instead of decompiling the compiled JAR.

What a JAVA file is

There is no separate binary “JAVA” format. A .java file is plain-text Java source code containing classes, interfaces, methods, package declarations, and imports. It can be edited and compiled with javac, subject to the required libraries and Java release level being available.

One JAR normally produces many source files. Their folders should match package names: com.example.Main belongs in com/example/Main.java. Java requires a public top-level class to use the same filename as that class.

Extract existing source first

List the archive contents with the JDK jar command:

jar tf app.jar

If the listing contains .java files, extract them into an empty working directory:

mkdir recovered-src
cd recovered-src
jar xf ../app.jar

If a matching source archive is available, extract that instead:

jar xf app-sources.jar

Do not mistake resources such as .properties, XML files, images, or service definitions for Java source. Extract them if needed by the project, but they cannot be converted into meaningful .java code.

Decompile compiled classes

If the JAR contains only .class files, use a desktop Java decompiler. CFR is a suitable command-line option and generally handles newer Java bytecode better than many older decompilers. Download CFR from its official project site, then run:

java -jar cfr.jar app.jar --outputdir recovered-src

CFR writes recovered .java files under recovered-src. For a graphical option, open the JAR in JD-GUI and select File → Save All Sources; JD-GUI creates a ZIP archive that must be extracted before the files are opened in an IDE.

IntelliJ IDEA can display decompiled classes for inspection, but CFR or JD-GUI is preferable when an exportable source tree is required. For small, public, non-sensitive samples, browser services such as Decompiler.com can decompile JARs without local installation; check its retention and privacy terms before uploading anything.

Compilation and recovery limits

Decompiled output is not the original source project. Bytecode does not preserve comments, formatting, most local variable names, test sources, build scripts, version-control history, and some generic type information. Obfuscation can replace meaningful names with identifiers such as a and b.

The recovered files may not compile immediately. Add the JAR's original dependencies, generated code, annotation processors, resources, and compiler options; then compile for the Java release used by the original classes. A newer class-file version may require a newer JDK and a decompiler that supports that version.

Multi-release JARs can contain alternate class implementations under META-INF/versions/, and shaded JARs can bundle dependencies alongside application code. Review the package structure and manifest before treating every recovered class as part of one source project.

Keep private, customer, licensed, or security-sensitive JARs on a local machine rather than uploading them to an online decompiler. Decompile only software that you own or are authorized to inspect; recovered code remains subject to its original license and copyright terms.