Occasionally when running a JAVA program, you'll run into an error where an Unsupported major.minor version 52 message (the number varies depending on the class version) is printed and the program fails to run correctly.
The Unsupported major.minor version error, translated literally, means "unsupported major/minor version." You can think of it as a JAVA version-related error.

JAVA is a compiled language, so the code a developer writes takes the form of a .java file. Compiling this translates it into a .class file that the JVM (Java Virtual Machine) can read. In other words, you write your code in a language humans can understand, while the actual execution goes through compilation into a language the computer can understand.
As of this writing, JAVA has been released up through version 16. JAVA's history isn't short, and it has continuously gone through both minor and major version updates throughout that time.
The problem is the compatibility issues that arise as a result. For instance, running a .class file compiled with version 1.5 on a 1.8 environment, or vice versa. Fortunately, JAVA guarantees backward compatibility. A 1.8 environment guarantees execution of .class files compiled with 1.8 or earlier. But conversely, it doesn't provide forward compatibility. That makes sense — maintaining compatibility would require correctly translating the structure between each version, and there's no way to know the structure of a future version that hasn't been developed yet...

In other words, the Unsupported major.minor version error occurs when the JAVA code you're trying to run was compiled with a version higher than the JAVA environment on your PC.

Ultimately, you need to upgrade your JAVA version to match or exceed the required version. There are two main approaches.

This is an option worth trying if you have the full program source code.
If you downgrade the JAVA version and recompile, the program's JAVA version becomes lower, allowing it to run in an environment with a much lower version than before.

However, there's a condition. As JAVA versions have been upgraded, various new patterns and syntax have been added. If you actively used features introduced starting in version 1.8, you'll get compile errors on version 1.7 or earlier.
That makes sense, since features introduced in 1.8 simply aren't implemented in 1.7.

In this case, you'll need to refactor the program's code into a more universally compatible form.

This is an option worth trying if you only have the .class file, if downgrading is difficult due to the issue mentioned above, or if you're looking for a simpler approach. Just upgrade the JAVA version on your PC and run the program.

Since JAVA maintains backward compatibility, there are no particular conditions to worry about here.

This error can sometimes show up while using Tomcat. But occasionally, even after compiling to match the JAVA version installed on the PC, the error still won't go away.
In this case, the accompanying symptom is that accessing the Servlet Context results in a 500 error on the first request (caused by the Unsupported major.minor version error), followed by nothing but 404 errors afterward. If you haven't experienced this before, or don't have much experience with it, running into this issue will almost certainly cause you a lot of trouble. That's because the root cause — the Unsupported major.minor version error — isn't visible, so people end up searching for or asking about information related to the Servlet's 404 error behavior instead. Naturally, other people who aren't aware of the actual circumstances can only respond with answers about the 404 error. This situation is genuinely frustrating. And no, this definitely isn't from personal experience or anything.

If you run into a 404 error despite having a perfectly valid Servlet as described above, check whether JRE_HOME is set among your environment variables.
Occasionally, certain development programs set JRE_HOME on their own without asking. The problem is that when both JAVA_HOME and JRE_HOME environment variables are set, Tomcat prioritizes JRE_HOME. In other words, the JRE's version gets applied.

For example, suppose JAVA_HOME is version 1.8 and JRE_HOME is version 1.6. Since compilation always requires a JDK, compilation is performed using JAVA_HOME's version, 1.8. However, when Tomcat runs, due to its tendency to prioritize JRE_HOME, it ends up running under version 1.6. As a result, code compiled with version 1.8 ends up being run under 1.6, and since the versions don't match, the error occurs.