#374 Checkstyle fails when IDE runs on JDK 1.7 and code is cross-compiled with JDK 1.8

[Karl Trygve Kalleberg]

(This is a problem with Eclipse Checkstyle Plug-in 6.1.0.201411141422, but this Milestone is not available in the Milestone pulldown.)

I'm running Eclipse 4.4.1.M20140925-0400 (Luna) on Ubuntu 14.04 LTS with the 1.7 OpenJDK (OpenJDK Runtime Environment (IcedTea 2.5.3) (7u71-2.5.3-0ubuntu0.14.04.1)).

I have the 1.8 Oracle JDK installed separately (Java(TM) SE Runtime Environment (build 1.8.0_20-b26)), and configured in Eclipse as the default JRE.

Checkstyle is giving me these errors in the Problems view:

Got an exception - java.lang.UnsupportedClassVersionError: for/bar/baz/SomeException : Unsupported major.minor version 52.

Admittedly, this might not be a case you want to support: Running the IDE on JDK 1.7 while cross-compiling/developing for 1.8, For various (plugin compatibility) reasons, we want to run our IDE on 1.7 for now, but still be able to develop for 1.8.

If it so happens that supporting this cross-compilation (cross-version) scenario is simple enough to add to the Checkstyle Plug-in, I hope you would consider adding it in a future release.

[Lars Koedderitzsch]

Hi,
yes, this problem always occurs when running Eclipse (and therefore Checkstyle) with a lower JDK version than the project compile target.
The problem surfaces with 2 checks, JavadocMethod and RedundantThrows - as these are the only 2 checks resorting to loading classes from the project classpath (in order to figure out exception types).

The 1.7 JDK simply cannot load classes compiled for target 1.8 and sadly there's no fix for that except running Eclipse on 1.8 too. I would not expect this to cause any problems, actually.

Even if Checkstyle wanted to support this scenario, they simply couldn't as this is a fundamental restriction of the Java VM.

In case you want to follow up on this, you might do better over at the Checkstyle core project itself, as this is just the Eclipse plugin project and the functionality triggering this problem is located in the Checkstyle core.

Kind regards,
Lars

[Lars Koedderitzsch]

The Checkstyle guys are planing on retiring their reliance on classloading for the 2 aforementioned checks (in fact RedundantThrows check was even removed in CS 6.2).
If that happens the problem won't exist anymore.