java.lang.UnsupportedClassVersionError

When running an application named StoreFrontService, we have run into this exception:

• java.lang.UnsupportedClassVersionError

In this article, we will examine what it is and how to resolve it.

Class Loading Phases

There are three phases in class loading^[1]:

• Loading
• See below
• Linking
• Bytecode verification^[6]
• Checks the classfile semantics, checks the constant pool symbols, and does type checking
• Preparation
• Creates and initializes static fields to standard defaults and allocates method tables
• Initializing
•  Runs the class static initializers, and initializers for static fields

For a given Java class or Java interface, the load class phase takes its name, finds the binary in Java classfile format, defines the Java class, and creates a java.lang.Class object to represent that given Java class or Java interface.

The load class phase can throw a NoClassDefFound error if a binary representation of a Java class or Java interface cannot be found. In addition, the load class phase does format checking on the syntax of the classfile, which can throw a ClassFormatError or UnsupportedClassVersionError.

The Exception

In our expriement, we have seen the following exception being thrown:

####<Mar 21, 2013 8:16:43 AM PDT> <Error> <Class Loaders> <sfperf-x6250-10> <MS_1> <[ACTIVE] ExecuteThread: '8' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1363879003661> <BEA-2162500> <Class, oracle.fodemo.storefront.store.service.server.serviceinterface.StoreFrontServiceImpl, was compiled with an incompatible version of Java. Make sure that all the classes needed by the application have been compiled with a compatible java version. java.lang.UnsupportedClassVersionError: oracle/fodemo/storefront/store/service/server/serviceinterface/StoreFrontServiceImpl : unsupported classversion 51.0
java.lang.UnsupportedClassVersionError: oracle/fodemo/storefront/store/service/server/serviceinterface/StoreFrontServiceImpl : unsupported classversion 51.0
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:14

      

This turns out to be that our application StoreFrontService was compiled in JDK 7 (class version: 51)^[7] and we were running it on JRockit bundled with Java 1.6 VM (class version: 50). The compiler is not backwards compatible^[2] because bytecode generated with JDK 7 won't run in Java 1.6 VM (unless compiled with the -target 1.6 flag^[3]). But the JVM is backwards compatible, as it can run older bytecodes.

References

1. Java Performance by Charlie Hunt, Binu John, David Dagastine 
2. Is JDK “upward” or “backward” compatible?
3. Cross-Compilation Options
4. Java SE 6 vs. JRE 1.6 vs. JDK 1.6 - What do these mean?
5. JRockit Version Information
6. Java Virtual Machine Specification
7. Unsupported major.minor version 51.0

JRockit Version Information

There are at least three version  numbers of interest for each JRockit release:

1. JRockit JVM version
2. JDK version
3. Mission Control version

JDK Version and JVM Version

To obtain the version number of the JDK and JVM, you execute the following command from the prompt:

• java -version

For example, this is displayed from my system:

java version "1.6.0_24"
Java(TM) SE Runtime Environment (build 1.6.0_24-b07) 
Oracle JRockit(R) (build R28.1.3-11-141760-1.6.0_24-20110301-1432-linux-x86_64, compiled mode)

Each version of the JRockit JVM is built for several different JDKs. Oracle JRockit R28 supports the following Java versions:

• J2SE 5.0
• Java SE 6

Ensure that your application complies with the Java specification corresponding to the Oracle JRockit release that you use.

You can find two pieces of information from the above output:

1. JDK version
• "1.6.0_24" is the JDK version being bundled with the JVM
• In other words, Java 1.6 is supported and it is bundled with the JDK classes from update 24-b07.
2. JRockit JVM version
• R28.1.3-11-141760-1.6.0_24-20110301-1432-linux-x86_64
• Version number:  R28.1.3
• Build number:  11
• Change number:  141760
• Date and Time: 20110301-1432 (in  compact ISO 8601 format)
• JVM is built for:
• OS: Linux
• CPU Architecture: x86_64

Mission Control Version

The JRockit Mission Control tools suite includes tools to monitor, manage, profile, and eliminate memory leaks in your Java application without introducing the performance overhead normally associated with tools of this type.

The version number for JRockit Mission Control can be gathered from command prompt by executing:

• jrmc -version

The output should look like this:

Oracle JRockit(R) Mission Control(TM) 4.0 (for JRockit R28.0.0)
  java.vm.version = R28.1.3-11-141760-1.6.0_24-20110301-1432-linux-x86_64
  build = M4.0.1-19
  chno = 134472
  jrmc.fullversion = 4.0.1
  jrmc.version = 4.0
  jrockit.version = R28.0.0
  year = 2010

The frst line tells us what version of Mission Control this is and what version of JRockit it was created for. The java.vm.version line tells us what JVM Mission Control is actually running on.

References

1. Oracle JRockit--The Defnitive Guide
2. J2SE 5.0
3. Java SE 6
4. Oracle® JRockit Installation and Upgrade Guide Release R28
5. JRockit Mission Control
6. Oracle® JRockit Command-Line Reference Release R28