I've just spent 2 days reinstalling my machine, with the worst part being the following problem. Since I didn't find any good Google hits, I thought I'd recount the problem and fix for others to follow.
My main goal was the upgrade of my OpenGamma work Windows 7 PC from a hard disk to an SSD. As part of this, I was joining a Windows Domain. As such, I ended up reinstalling Windows 7 from scratch and recreating my entire work environment. The PC in question is 64 bit, which was key to the problems.
After the fresh install of Windows 7, I reinstalled JDK 1.5, then JDK 1.6. Only then did I install Eclipse (3.5). When I tried starting Eclipse, it failed immediately, displaying its command line arguments.
To fix this strange error (which I'd not seen before) I changed the eclipse.ini OSGI -Dosgi.requiredJavaVersion=1.5 line to 1.6. This change got Eclipse up and running.
I installed all the Eclipse plugins I needed including Eclipse-CS for Checkstyle.
When I then imported our source code I got an UnsupportedClassVersionError referencing a number of seemingly random files. The problem marker referred to the whole file with a lovely Eclipse red cross. The only reference to checkstyle was the problem type of 'Checkstyle problem'.
By uninstalling all the checkstyle setup, I got everything to compile. So it was definitely something to do with Eclipse-CS or Checkstyle.
Some Googling did reveal that the cause for the random files was that those files contained a Javadoc @throws clause referring to a custom exception class (not a JDK exception class). So, there was something in Eclipse-CS or Checkstyle that couldn't cope with this, and it had something to do with an invalid Java version. (UnsupportedClassVersionError refers to a class that was compiled under one version of the JDK and is then being run under an earlier version)
But, I had no idea what that issue was, or how to solve it. Or why it was different on this new install as opposed to my old install.
This morning I decided to go back and think about the first problem that I'd worked around - the failure of Eclipse to startup normally. I did java -version on each of the four Java installs, JDK 1.5 and 1.6 on each of the old and new disks. On the old hard disk, both were 64 bit JDK installs. On the new SSD, JDK 1.6 was 64 bit, but JDK 1.5 was 32 bit.
So, I uninstalled the two SSD JDKs, and reinstalled them, both as 64 bit. I also needed to install the browser JRE separately as that needed a 32 bit JRE.
Eclipse now started correctly (with either the OSGI 1.5 or 1.6 setting) and the Eclipse-CS/Checkstyle problem went away.
I've still no idea why the difference between a 32 and 64 bit JVM should cause an UnsupportedClassVersionError though. I've always thought that the bytecode format was independent of 32 vs 64 bit, yet the error would appear to indicate otherwise.
At least it is sorted now. The newly installed SSD drive is going to have to be super-quick for the two day loss of productivity though!
I guess it has something todo with eclipse's native launcher. Most likely it thinks to know better which java to start ;)
ReplyDeleteI had almost the same problem, in a similar context : newly installed Windows 7 64 bits, SSD, JDK 5 64 bits and JDK 6 64 bits installed then Eclipse Gallileo 32 bits, because 64 bits was not available.
ReplyDeleteAnd I had the command line argument as a popup.
Now that Helios 64 bits is available I have installed it and there is no pb with Helios (for now).
Hi,
ReplyDeletethat sort of problems usually happen when you try to load a "higher version" class file in a "lower version" JVM.
Indeed eclipse-cs (better Checkstyle for that matter) is trying to load exception classes of your workspace projects during the checking process.
This means such errors could happen if you run Eclipse on a 1.5 JVM but your project/workspace setting make eclipse compile for target 1.6.
In that case your projects classes have a higher class version number than the 1.5 JVM eclipse is running on can actually load.
From your article I couldn't exactly deduce if such a setup was actually the case...
BR,
Lars