How to Fix UnsupportedClassVersionError in Java: JRE vs JDK and Version Mismatch

By the end of this page, you will understand what java.lang.UnsupportedClassVersionError means, why it happens when your compiled Java class and runtime Java version do not match, and how to fix it by checking your Java versions, installing the JDK when needed, and using the correct PATH settings.

UnsupportedClassVersionError means that a .class file was compiled for a newer Java version than the one currently trying to run it.

In Java, source code is first compiled into bytecode by javac, and then that bytecode is executed by the Java runtime using java.

That means there are two different version checks involved:

• Compile-time version: the Java version used by javac
• Run-time version: the Java version used by java

If the compiler creates bytecode for a newer Java release, but the runtime is older, the runtime cannot understand that bytecode and throws UnsupportedClassVersionError.

For example:

• major version 51.0 = Java 7
• If your class was compiled with Java 7
• but you run it with Java 6 or older
• you will get this error

Why this matters

This is common in real projects because developers often have:

• multiple Java versions installed
• a JRE without a full JDK
• an editor or IDE using a different Java version than the terminal
• build tools compiling with one version and running with another

JRE vs JDK

JRE

The Java Runtime Environment is used to run Java programs.

It includes:

• the java command
• core libraries
• the JVM

It usually does not include the Java compiler.

JDK

The Java Development Kit is used to develop Java programs.

It includes everything in the JRE, plus development tools such as:

• javac for compiling
• jar
• javadoc
• debugging and development tools

If you want to compile Java source code, you need the JDK.

The key fix

To solve this error, make sure:

1. You have a JDK installed.
2. javac and java are from compatible versions.
3. Your editor is using the same Java installation you expect.
4. If needed, compile for an older target version.

Think of Java like writing a document in a newer file format.

• javac is the app that saves the file.
• java is the app that opens the file.

If you save the file in a format from a newer version, but try to open it with an older app, it fails.

That is exactly what happens here:

• the compiler produced newer bytecode
• the runtime is too old to read it

So the fix is usually one of these:

• upgrade the runtime
• compile for an older Java version
• make sure the compiler and runtime come from the same Java installation

The main commands to check are:

java -version
javac -version

If these show different Java versions, that is often the problem.

Example: compile and run normally

public class Hello {
    public static void main(String[] args) {
        System.out.println("Hello, World");
    }
}

Compile:

javac Hello.java

Run:

java Hello

This works when both commands use compatible Java versions.

Example of a mismatch

Suppose:

javac -version

shows:

javac 1.7.0

but:

java -version

shows:

java version "1.6.0"

Then code compiled by Java 7 may fail at runtime on Java 6 with an error like:

Unsupported major.minor version 51.0

Compile for an older version

If you must run on an older Java version, you can compile for that version.

Example for older Java tools:

javac -source 1.6 -target 1.6 Hello.java

This tells the compiler to accept Java 6 syntax and produce Java 6 bytecode.

Note: this only works if your code and libraries are compatible with that older version.

Consider this simple file:

public class Hello {
    public static void main(String[] args) {
        System.out.println("Hello");
    }
}

Now imagine these steps:

1. You write Hello.java.
2. javac Hello.java compiles it.
3. The compiler creates Hello.class.
4. That .class file contains bytecode with a class version number.
5. java Hello starts the JVM.
6. The JVM reads Hello.class.
7. The JVM checks whether it understands that class version.
8. If the class version is newer than the JVM supports, it throws UnsupportedClassVersionError.

Small trace example

If your system is set up like this:

• javac = Java 7
• java = Java 6

then this happens:

javac Hello.java   -> creates Java 7 bytecode (major version 51.0)
java Hello         -> Java 6 tries to load the class
                    -> Java 6 does not support 51.0
                    -> error is thrown

Useful class version examples

So in your error:

Unsupported major.minor version 51.0

51.0 tells us the class was compiled for Java 7.

This concept appears often in real Java development.

Running apps on servers

A program may be compiled on a developer machine with Java 17, but the production server may still run Java 11. The application starts failing immediately.

Using build tools

A Maven or Gradle build may compile with one JDK while your terminal uses another runtime.

Working in editors and IDEs

An editor like Notepad++, VS Code, or IntelliJ may use a configured JDK internally, while your command line uses a different java from PATH.

Using third-party libraries

Even if your own code is simple, a dependency may be compiled for a newer Java version than your runtime supports.

School or lab computers

A shared machine may have an old runtime installed globally, while you compile code using a newer local toolchain.

In real projects, developers usually avoid this problem by making the Java version explicit.

Common patterns

Use one JDK for both compile and run

Teams often configure a single JAVA_HOME and use its bin directory so java and javac come from the same installation.

Validate the environment early

Build scripts often check the Java version before doing anything else.

java -version
javac -version

This is a simple guard clause for environment problems.

Set a target Java version in the build

Projects usually declare the Java version they support.

Examples:

• Maven compiler target/source
• Gradle sourceCompatibility and targetCompatibility
• CI pipelines pinned to a specific JDK

Keep runtime compatibility in mind

If an application must run on Java 8 servers, the build should produce Java 8-compatible bytecode.

Rebuild after changing Java versions

Old .class files can remain after switching JDKs. Developers often clean and rebuild to avoid stale output.

1. Installing only a JRE when you need to compile

If you want to compile Java source code, a JRE is not enough.

Broken assumption:

I installed Java, so javac should work.

But on many systems, only the runtime is installed.

Fix:

• install a JDK
• verify javac -version

2. java and javac come from different installations

This is one of the most common causes.

Example problem:

java -version
# shows 1.6

javac -version
# shows 1.7

Fix:

• update PATH
• use one JDK consistently
• check JAVA_HOME if your tools use it

3. Changing PATH but not restarting the editor or terminal

Some applications keep using the old environment values.

Fix:

• close and reopen Notepad++
• open a new terminal window
• verify the version again

4. Compiling once, then running an old .class file

You might think you are testing new code, but an older incompatible class file is still being used.

Fix:

• delete old .class files
• recompile cleanly

5. Confusing source compatibility with runtime compatibility

This is broken reasoning:

My code syntax is simple, so it should run everywhere.

Even simple code can fail if the bytecode was compiled for a newer Java version.

6. Pointing PATH to a JRE when developing

A JRE may let you run java, but not javac.

Better approach:

• put the JDK bin directory in PATH
• ensure both compile and run commands use it

PATH to JRE vs PATH to JDK

For development, the JDK bin directory is normally the correct choice.

java -version
javac -version

• java runs compiled classes
• javac compiles .java files
• Use a JDK if you are developing Java code
• UnsupportedClassVersionError means runtime Java is too old for the class file

Common class versions

Typical fix steps

1. Install a JDK
2. Check:
   • java -version
   • javac -version
3. Make sure both are compatible
4. Point PATH to the JDK bin
5. Restart terminal/editor
6. Clean old .class files and recompile

Older compile target example

javac -source 1.6 -target 1.6 Hello.java

Rule of thumb

• Developing Java? Use JDK
• Running Java only? JRE may be enough
• Same compiler and runtime version is the safest setup

What does Unsupported major.minor version 51.0 mean?

It means the class file was compiled for Java 7, but you are trying to run it with an older Java runtime.

Do I need a JDK or just a JRE?

If you want to compile Java code, you need a JDK. A JRE is only for running Java programs.

Should my PATH point to the JDK or the JRE?

For development, it should usually point to the JDK bin directory.

Why does my program compile but not run?

Because javac may be using a newer Java version than java.

How do I check which Java version is being used?

Run:

java -version
javac -version

Can I compile for an older Java version?

Yes, if your code is compatible. Use compiler options such as:

javac -source 1.6 -target 1.6 Hello.java

Why does this happen in editors like Notepad++?

The editor may be configured to use a different Java installation than your terminal or system PATH.

Is this error caused by my Java source code?

Usually no. It is usually an environment or version mismatch problem, not a syntax problem in your code.

• Java bytecode — UnsupportedClassVersionError is about bytecode version compatibility.
• JVM — the JVM loads class files and rejects unsupported versions.
• JDK — needed for compiling Java source code.
• JRE — used for running Java applications.
• PATH environment variable — controls which java and javac commands are found.
• JAVA_HOME — many tools use this to locate the Java installation.
• Compilation — source code must be compiled into .class files before running.
• Build tools — Maven and Gradle often manage Java version settings in real projects.