Java class and JAR viewer: which Java version does it need?

What it shows

• The Java version it needs. Every class file records the version of the class format it was compiled to, in bytes 4 to 7. For a jar, every class is read and summed up, for example “All 37 classes outside META-INF/versions/ run on Java 8 or newer; META-INF/versions/9/ holds 1 class compiled for Java 9”. If a few classes need a newer Java than the rest, it names them. Those are the ones that throw UnsupportedClassVersionError halfway through a run.
• The manifest. Main-Class (and whether that class is really in the jar), Automatic-Module-Name, Multi-Release, Class-Path, Created-By, the Implementation and OSGi Bundle versions, Spring Boot's Start-Class, and agent entries. The full META-INF/MANIFEST.MF is one click away.
• Libraries inside. Every META-INF/maven/group/artifact/pom.properties as group:artifact:version. A “fat” or shaded jar carries one for each library copied into it, which is what you need when a security advisory names a library version. Jars nested in BOOT-INF/lib/ or WEB-INF/lib/ are listed too.
• Who signed it. For a signed jar, the signer certificate from META-INF/*.RSA, .DSA or .EC: name, issuer, validity dates and SHA-256 fingerprint, plus the digest algorithm in the .SF file.
• Every package and class. Pick one to see its access flags, superclass and interfaces, its fields and methods written as Java declarations (generic types included, from the Signature attribute), its annotations, and the text strings in its constant pool, searchable. Each method opens to a bytecode listing in the format of javap -c.

What it cannot do

• No decompiling. You see signatures and bytecode, not the Java source. Decompilers such as CFR, Fernflower (in IntelliJ) and Procyon rebuild something close to the source; they run on your own computer.
• Nothing runs. The page reads bytes and never loads or executes a class. It cannot say what the program does when it runs, and it is not a malware scan.
• Obfuscated names stay obfuscated. A class that ProGuard renamed to a.b.c is shown as a.b.c. Only the build's mapping file can reverse that.
• Signatures are not verified. The signer certificate is read and fingerprinted, but the digests are not checked against the classes. jarsigner -verify does that.
• Android code is different. An .apk holds Dalvik bytecode (classes.dex), not class files. The APK viewer reads those apps.

Class file versions and Java releases

The number after “class file version” in a Java error is the major version of the class. Since Java 5 the rule is simple: Java N writes major version 44 + N. A JVM runs every class up to its own number and refuses anything newer.

Useful to know

Reading the error

UnsupportedClassVersionError: com/example/App has been compiled by a more recent version of the Java Runtime (class file version 61.0), this version of the Java Runtime only recognizes class file versions up to 52.0 means App needs Java 17 (61) and the java that ran it is Java 8 (52). Either run it with Java 17 or newer (check with java -version; an IDE or build tool may use a different Java than your terminal), or rebuild the code with javac --release 8 (Maven: <maven.compiler.release>8</maven.compiler.release>).

Build-Jdk-Spec is not the version you need

The manifest's Build-Jdk-Spec or Created-By says which Java ran the build, not which Java the classes target. Apache Commons CLI 1.9.0 is an example: its manifest says Build-Jdk-Spec: 17, but its classes are version 52 and run on Java 8. Only the class files tell you the version they need.

Multi-release jars

Since Java 9, a jar whose manifest says Multi-Release: true can carry extra copies of classes under META-INF/versions/N/, which Java N and newer load instead of the base ones. Older Javas ignore that folder, so the base classes set the minimum. Many libraries put just a module-info.class in META-INF/versions/9/ to become a named module while still running on Java 8.

Preview features

A class compiled with --enable-preview has minor version 65535. It runs only on exactly the Java release that compiled it, started with --enable-preview, and the page says so.

Constant pool strings

Every text literal in a class's code (messages, SQL, URLs, property names, sometimes a hard-coded password) is stored as plain text in its constant pool. Searching the strings is the quickest way to see what a class talks to without decompiling it.