My version of Java will compile, but not run, Java programs

I recently took a look at some Java programs that were created as part of a home study course.

I innocently compiled one of them, which worked OK and without error. When I tried to run it using the Java command it generated the following error:

Exception in thread "main" java.lang.UnsupportedClassVersionError: MathDemo2 has been compiled by a more recent version of the Java Runtime (class file version 69.0), this version of the Java Runtime only recognizes class file versions up to 52.0        at java.lang.ClassLoader.defineClass1(Native Method)        at java.lang.ClassLoader.defineClass(Unknown Source)        at java.security.SecureClassLoader.defineClass(Unknown Source)        at java.net.URLClassLoader.defineClass(Unknown Source)        at java.net.URLClassLoader.access$100(Unknown Source)        at java.net.URLClassLoader$1.run(Unknown Source)        at java.net.URLClassLoader$1.run(Unknown Source)        at java.security.AccessController.doPrivileged(Native Method)        at java.net.URLClassLoader.findClass(Unknown Source)        at java.lang.ClassLoader.loadClass(Unknown Source)        at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)        at java.lang.ClassLoader.loadClass(Unknown Source)        at sun.launcher.LauncherHelper.checkAndLoadMain(Unknown Source)

I must stress, the Javac command worked without error, but the Java command seems to have 'issues' - to say the least..!

Could anyone say what can be done to resolve this error?  At the moment I am reluctant to compile any other Java programs as this will render them unrunnable.

I look forward to any help or input and hope to this issue resolved soon.

I am running Windows 11 and have installed Java 8 update 471.

Java Runtime wrote:Exception in thread "main" java.lang.UnsupportedClassVersionError:
MathDemo2 has been compiled by a more recent version of the Java Runtime (class file version 69.0),
this version of the Java Runtime only recognizes class file versions up to 52.0

The error message is telling you that class was compiled using Java 25 (version 69.0), but it attempted to be run using Java 8 (version 52.0).

How are you running the javac and java commands?  If the OS uses the PATH environment variable to find those commands, it looks like the path to the java command is before the path to the javac command.  I assume there is a java command of the same version as the javac command in the same folder.  Because the other java command (version 8) is earlier on the PATH then it is used instead of the one with the javac command.
Some solutions - Move the path to the java 8 version to after the path for the java 25 version
Use batch files with explicit paths to the commands to compile and execute the code

It's probably because 'java' and 'javac' commands are pointing at two different jdk installations.
IIRC on windows you could find the installation path using Get-Command
Syntax would be like:
Get-Command java -All
And
Get-Command javac -All

About how to configure defaults on windows though, I have no idea :P

To find the version of java, the command-line command is "java -version". Should work also for the javac command.

a JDK/JRE is completely self-contained and the executables are mostly found in the %JAVA_HOME%\bin directory, where JAVA_HOME is the location of directory that is the root of the Java version you want.

So ordinarily, JAVA_HOME will be set as a system or user environment variable to point to something like C:\PROGRAM_FILES\java-versionxxx.  You'd then put that in the PATH adding it as %JAVA_HOME%\bin. Please remember the "bin" part in the PATH! Also, the Windows command-line parser historically would get confused if you referenced a file or directory with a space in it and supply an 8.3-format alias, typically something PROGRA~1. Use if you cannot get the full space-containing name to work.

That's all you'd normally need.

Note that unlike Internet (There Can Be Only One!) Explorer, you can have multiple JDKs and JREs installed in Windows and even run them simultaneously. Which a production server running multiple Java apps might do. While you can use environments/PATH settings, you can also invoke java and javac by their explicit filesystem pathnames, although that can be a pain. But whatever you do NOT simply "cd" into the JDK directory or one of its subdirectories!  They are not intended to be used as working directories.

Thanks to all of those who have replied to this post and I can now tag it as Problem Fixed..

The solution comprised 2 changes to the System Environment variables: the first being (as mentioned by several helpful persons) to change the path System Variable so that the reference to the JAVA_HOME system variable comes first, in the list and reads %JAVA_HOME%\bin.  This, in my installation, points to C:\Program Files\Java\jdk-25\bin and crucially contains both java.exe and javac.exe.

The second change was to alter the path for the JAVA_HOME variable so that it reads: C:\Program Files\Java\jdk-25\ NOT with the folder name bin at the end..!  Clearly this confused the parser - when it came to the path variable it would have read C:\Program Files\Java\jdk-25\bin\bin and not found a bin folder within the first one so that it then went to the next entry which does - as before.

In simple terms before the order of references in the Path variable was changed, the first reference was to C:\Program Files (x86)\Common Files\Oracle\Java\javapath which does not have a javac.exe file, so when a javac command was issued it defaulted to C:\Program Files\Java\jdk-25\bin which does, which is Java 25,  version 69. This is successful, but a subsequent java command uses the one in the first folder which is Java 8, version 58 but fails because the Java runtime only recognises class file versions up to 52.

Many thanks, once again and this has certainly ironed out some inconsistencies in my System Environment variables regarding Java..

Stuart Lord wrote:. . . it would have read C:\Program Files\Java\jdk-25\bin\bin and not found a bin folder . . .

That is exactly what would happen. The problem is, that such a PATH error will fail silently. The OS will move to the next entry in the PATH until it finds a java.exe program (Windows® format) without telling you what is happening. You were lucky that it produced another error quickly, with an error message that whoever replied to your query recognised immediately.