Today, Deploy static resource packages come into our Production environment. Only static resource files, such as database connection information, SQL query statements, are involved in the package. After successful deployment, the following error occurred when starting the service:

Exception in thread "main" java.lang.UnsupportedClassVersionError: JVMCFRE003 bad major version; class=support/operations/gtm/iosbackendmanager/BackendManager, offset=6
    at java.lang.ClassLoader.defineClassImpl(Native Method)
    at java.lang.ClassLoader.defineClass(ClassLoader.java:324)
    at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:155)
    at java.net.URLClassLoader.defineClass(URLClassLoader.java:715)
    at java.net.URLClassLoader.access$400(URLClassLoader.java:94)
    at java.net.URLClassLoader$ClassFinder.run(URLClassLoader.java:1169)
    at java.security.AccessController.doPrivileged(AccessController.java:492)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:598)
    at java.lang.ClassLoader.loadClassHelper(ClassLoader.java:777)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:750)
    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:341)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:731)
    at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:495)
</verbosegc>

After analysis and investigation, we think it is a JDK level problem of the local RAD (one of eclipse). The java version on server is 1.7, the source and target involved in Ant packaging are 1.7, but the JDK compiled version of the local RAD is 1.8, which is changed to 1.7. After packaging and deploying, the process starts normally.

The common saying on the network about this problem is "because we try to run on a lower version of the JVM with a Java class file compiled with a higher version of JDK", so the solution is usually to change the local JDK compilation environment. A typical example is this: UnsupportedClassVersionError: JVMCFRE003 bad major version in WebSphere AS 7 In this case, however, the part of my deploy ment does not involve any compiled class es. So there are two questions here:

1. What does offset=6 mean?
2. Does the version of the JDK compilation environment affect the compilation of static resources?

This is also the first time this part has been deployed using the Automated Packaging and Deployment Tool (UCD). Because it is a production environment, there are two main issues expected before making this Change:
1, Deploy process problem, 2, static resource scrambling problem.
The first one did fail a little, no change in the bin path, but "allow failure" was not selected in the process step, so when you copy the bin folder, you will report that the folder is empty and stop running. Just select allow failure.
2. The problem of scrambling is the same as before, and the current symbol is more involved in this version of the change: "". Therefore, only files can be saved as ISO-8859-2 in Eastern Europe encoding. This requires more investigation and the source code's processing logic for utf8 and other format encoding.
This time, the expected problems did not occur. Instead, strange problems occurred. Everyone was nervous and the problem was solved. However, more investigation is needed.

how to check the jdk version used to compile a .class file - duplicate