Coobbi
HomeAppsTutorialsJre4AndroidJar File OpenerContact

How to Decompile CLASS Files on Android

Inspect compiled Java classes inside a JAR and understand what readable source a decompiler can—and cannot—reconstruct.

Quick answer

Open a CLASS entry and choose the decompile view

A Java .class file contains JVM bytecode plus structured metadata such as class names, methods, fields and attributes. In Jar File Opener, open the containing JAR, select a CLASS entry and choose Decompile to Java when supported. The result is reconstructed Java-like code for inspection—not the exact original source file.

Decompile a CLASS file on Android

  1. Open Jar File Opener and select the JAR that contains the compiled class.
  2. Browse its package folders, such as com/example/, and locate the desired .class entry.
  3. Tap the entry and choose Decompile to Java when that view is available. Use the hex view when you need the raw bytes instead.
  4. Check the declared package, class name, superclass, interfaces, fields and methods in the reconstructed output.
  5. Review related inner classes such as Example$1.class or Example$Worker.class when a method appears incomplete.
  6. Treat the output as an analysis aid. Compare behavior with other classes and resources before drawing conclusions.

Decompiler, disassembler or hex viewer?

Decompile

Readable Java-like code

Reconstructs control flow, expressions and declarations from bytecode. Best for understanding likely program behavior.

Disassemble

JVM instructions

Shows bytecode operations, constant-pool references and method descriptors. More exact, but less similar to source code.

Class metadata

Structure and attributes

Reveals version numbers, access flags, fields, methods, interfaces, annotations and other stored attributes.

Hex view

Raw file bytes

Useful for confirming the CA FE BA BE magic number or diagnosing a damaged or incorrectly named file.

What a Java decompiler can usually recover

The JVM class format preserves enough structure for a decompiler to produce useful output. Depending on the compiler and included attributes, you may recover:

  • The binary class name, package, superclass and implemented interfaces.
  • Field names, types, modifiers and constant values stored in the class.
  • Method names, descriptors, return types, parameters and declared exceptions.
  • Annotations, generic signatures and source filename information when those attributes are present.
  • Loops, conditions, method calls and object creation reconstructed from bytecode instructions.
  • Line numbers and some local variable names when the compiler retained debugging tables.

What decompilation cannot reliably restore

Compilation transforms source into bytecode and may discard information. A decompiler generally cannot reproduce comments, whitespace, exact formatting, build files or the author's original expression choices. Local variable and parameter names may be missing. Compiler-generated bridge methods, synthetic classes, lambdas and optimized control flow may look unfamiliar.

Obfuscation can replace meaningful names and restructure code. Kotlin, Scala or other JVM-language bytecode may be rendered as awkward Java-like output. Two different source programs can compile to equivalent bytecode, so readable output should not be described as the original source.

What is stored in a CLASS file?

The Java Virtual Machine Specification defines a structured binary format. Every valid CLASS file begins with the four-byte magic value 0xCAFEBABE, followed by version information and tables describing the class.

ClassFile { magic minor_version, major_version constant_pool access_flags this_class, super_class interfaces fields methods attributes }

The constant pool stores symbolic information referenced elsewhere, including class names, strings, field references and method references. Method bytecode is stored in Code attributes. This structure makes static analysis possible without executing the class.

Inspect CLASS files with javap on a computer

Oracle's JDK includes javap, a disassembler rather than a source decompiler. It can show members, private declarations, descriptors, verbose metadata and JVM instructions.

javap Example.class
javap -private Example.class
javap -c Example.class
javap -verbose Example.class
javap -classpath app.jar com.example.Main

Why a CLASS file may not decompile

  • Unsupported class version: the file may have been compiled for a newer Java release than the decompiler understands.
  • Damaged data: a truncated file, invalid constant-pool reference or wrong magic number prevents correct parsing.
  • Not a Java CLASS file: an unrelated file may have been renamed with a .class extension.
  • Obfuscation: renamed symbols, encrypted resources or deliberately unusual bytecode can reduce readability.
  • Missing related classes: references can still be listed, but types or behavior may be difficult to understand without dependencies and inner classes.
  • Compiler-specific patterns: newer language features or bytecode emitted by a non-Java JVM language may not map cleanly to the decompiler's output model.
  • Multi-release archive: the JAR may contain different versions of a class under META-INF/versions/; make sure you selected the intended entry.

Use decompilation responsibly

Only inspect software you own or have permission to analyze. Copyright law, licenses, contracts and local rules can restrict reverse engineering or redistribution. Do not publish reconstructed code, credentials or proprietary material merely because a tool can display it. For security research, work on authorized targets and disclose findings responsibly.

CLASS decompilation FAQ

Is a CLASS file the same as Java source code?

No. A CLASS file is a compiled binary representation for the JVM. A decompiler reconstructs a source-like view from that representation.

Will decompiled code compile again?

Sometimes, but not always. Missing dependencies, synthetic constructs, inaccurate type inference or unsupported language features can require manual corrections.

Can decompilation recover comments?

Normally no. Source comments are not part of the standard class-file structures produced for JVM execution.

What does CAFEBABE mean?

CA FE BA BE is the four-byte magic number the JVM specification uses to identify the class-file format.

Does viewing a CLASS file execute it?

No. Static parsing, hex viewing, disassembly and decompilation read the file's bytes without invoking its methods.

Technical sources

Class structure follows Oracle's Java Virtual Machine Specification, Chapter 4. Desktop inspection commands follow the official javap documentation. Last reviewed August 14, 2026.