Question
How to Fix UnsupportedClassVersionError in Java: JRE vs JDK and Version Mismatch
Question
I am trying to use Notepad++ as a simple environment to edit, compile, and run Java code.
I have a JRE installed, and I added its bin directory to my PATH environment variable.
When I run a simple "Hello, World" program from Notepad++, I get this error:
java.lang.UnsupportedClassVersionError: test_hello_world : Unsupported major.minor version 51.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(Unknown Source)
...
It seems like this may be a Java version mismatch.
How can I fix this?
Do I need to install the JDK and point my PATH to the JDK instead of the JRE?
What is the difference between using the PATH entry from the JRE versus the JDK?
Short Answer
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.
Concept
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 Java programs.
Mental Model
Think of Java like writing a document in a newer file format.
javacis the app that saves the file.javais 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
Syntax and Examples
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:
Step by Step Execution
Consider this simple file:
public class Hello {
public static void main(String[] args) {
System.out.println("Hello");
}
}
Now imagine these steps:
- You write
Hello.java. javac Hello.javacompiles it.- The compiler creates
Hello.class. - That
.classfile contains bytecode with a class version number. java Hellostarts the JVM.- The JVM reads
Hello.class. - The JVM checks whether it understands that class version.
- 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 7java= Java 6
then this happens:
Real World Use Cases
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.
Real Codebase Usage
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
sourceCompatibilityandtargetCompatibility - 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.
Common Mistakes
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_HOMEif 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 file
Comparisons
| Concept | Purpose | Includes java | Includes javac | Best for |
|---|---|---|---|---|
| JRE | Run Java programs | Yes | No | End users running apps |
| JDK | Develop and run Java programs | Yes | Yes | Programmers building apps |
| Situation | Result |
|---|---|
Newer javac, older java | UnsupportedClassVersionError can occur |
| Same-version and |
Cheat Sheet
java -version
javac -version
javaruns compiled classesjavaccompiles.javafiles- Use a JDK if you are developing Java code
UnsupportedClassVersionErrormeans runtime Java is too old for the class file
Common class versions
| Class version | Java |
|---|---|
| 50.0 | 6 |
| 51.0 | 7 |
| 52.0 | 8 |
| 55.0 | 11 |
| 61.0 | 17 |
Typical fix steps
- Install a JDK
- Check:
java -versionjavac -version
- Make sure both are compatible
FAQ
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?
Mini Project
Description
Create a small command-line Java setup checker that helps you verify whether your development environment is ready to compile and run Java code correctly. This project demonstrates the exact issue behind UnsupportedClassVersionError: the difference between compiling and running, and the importance of using the correct Java tools.
Goal
Build and run a simple Java program, then verify that your environment uses the expected Java version for both compilation and execution.
Requirements
- Install a JDK and confirm that both
javaandjavaccommands are available. - Create a Java file that prints a message to the console.
- Compile the file using
javac. - Run the compiled class using
java. - Check and compare the output of
java -versionandjavac -version.
Keep learning
Related questions
Avoiding Java Code in JSP with JSP 2: EL and JSTL Explained
Learn how to avoid Java scriptlets in JSP 2 using Expression Language and JSTL, with examples, best practices, and common mistakes.
Choosing a @NotNull Annotation in Java: Validation vs Static Analysis
Learn how Java @NotNull annotations differ, when to use each one, and how to choose between validation, IDE hints, and static analysis tools.
Convert a Java Stack Trace to a String
Learn how to convert a Java exception stack trace to a string using StringWriter and PrintWriter, with examples and common mistakes.