Friday, 14 October 2011

Glassfish and Tomcat Problems with Java 7

Now that Java 7 is released (finally!), we've had a few reports of problems with our training courses that are using Tomcat or Glassfish.

Both Tomcat and Glassfish are running on top of the Java Runtime (the JVM) which is pointed to by your system's environment variables. When you install Java 7, your system should be updated to be using the version 7 JVM, which Tomcat and Glassfish should run on without problems.

However, some people are finding that after installing Java 7, the compiler is working just fine in their IDE, but at runtime their Tomcat is reporting errors such as the following (You may have to check carefully in the logs for these errors):

Exception in thread "main" java.lang.UnsupportedClassVersionError
or:
java.lang.VerifyError: Expecting a stackmap frame (followed by something scary looking).
Both errors point to that although your code was compiled using version 7, the runtime of your Tomcat or Glassfish is still on version 6 (or older), and eventually this will lead to a crash.

As a check, fire up a command prompt window (I'm assuming you're on Windows, these are the only reports we've had so far), and type the command:

java -version
This will give the runtime version (note that 1.7 means Java 7 and 1.6 means Java 6 - confusing huh?)

If you're seeing the wrong version, I cannot explain why this is happening because I've tried to replicate the situation myself but for me everything installed just fine.

A quick fix is to copy the file called "java.exe" from the directory in which you installed Java 7 (this is often c:\program files\java\jdk1.7.x\bin), across to the c:\windows\system32 directory (you will need to overwrite what is already there). It is probably also wise to copy across the javac and javaw exe files to the same directory.

Now try java -version again, you should now see version 1.7.

A Further Step for Glassfish 3.0 Users

I've discovered that a further step is needed if you're running on Glassfish 3.0. The startup script invokes a script in the glassfishv3/glassfish/config directory, called "asenv.bat". Bizarrely, in Glassfish 3, this script hardcodes the location of the JVM in the final line of the script.

Find the following instruction:

set AS_JAVA=C:\Program Files\Java\jdk1.6.0_25
You can safely delete this line. If the AS_JAVA variable isn't set, the startup script falls back to using just plain "java" to run the JVM (which will now be version 7).

(If you're interested, the reason the copy to system32 works is that your system PATH always includes the /windows/system32 directory. The Java installation program actually drops the JVM and Compiler into this directory, so they will always be found on the command line and by any tools wanting to run a JVM, such as Tomcat. I suspect that for some reason, some installations fail to make the copy and so you're left with the old version.)