Is this related to the following 1.520 change?

Core started relying on Java 1.6 as per the agreement in the dev list. If you have a serious objection against it, please let us know before we really start relying on 1.6 features.

Same problem here:

java.lang.ClassFormatError: Failed to load hudson.maven.ProcessCache$GetSystemProperties

It shouldn't be related to core using Java 6, it's a separated classloader, AFAIK.

We see the same problem. None of our Java5 Maven builds work any longer. Some of the classes in the maven-plugin.hpi are Java6 format:

[sweeney@hudson0 plugins]$ unzip -l -p maven-plugin.hpi 'WEB-INF/classes/hudson/maven/ProcessCache$GetSystemProperties.class' > xxx
[sweeney@hudson0 plugins]$ file xxx
xxx: compiled Java class data, version 50.0
[sweeney@hudson0 plugins]$ rm xxx
[sweeney@hudson0 plugins]$

We have to have Java5 artefacts because the target J2EE container runs atop Java5. We can work round this by using the Java6 compiler and modifying the build to explicitly request Java5-compatible artefacts, but that means changing several dozen jobs. If Java5 is deprecated in this release I would have expected to see something in the changelog.

After installing Jenkins 1.525 the builds using jdk1.5.0_12 still fail with UnsupportedClassVersionError

Notice that Jenkins-18403 break builds since 1.518, this issue arises after upgrade from 1.519 to 1.520

Hello, I have similar problem:

... /var/lib/jenkins/tools/hudson.model.JDK/Java_1.5_v22/bin/java -Xms512m -Xmx768m -cp /var/lib/jenkins/plugins/maven-plugin/WEB-INF/lib/maven-agent-1.3.jar:/var/lib/jenkins/tools/hudson.tasks.Maven_MavenInstallation/Maven_2.2.1/boot/classworlds-1.1.jar hudson.maven.agent.Main /var/lib/jenkins/tools/hudson.tasks.Maven_MavenInstallation/Maven_2.2.1 /var/cache/jenkins/war/WEB-INF/lib/remoting-2.28.jar /var/lib/jenkins/plugins/maven-plugin/WEB-INF/lib/maven-interceptor-1.3.jar 53755 /var/lib/jenkins/plugins/maven-plugin/WEB-INF/lib/maven2.1-interceptor-1.2.jar
<===[JENKINS REMOTING CAPACITY]===>channel started
ERROR: Failed to parse POMs
java.io.IOException: Remote call on Channel to Maven [/var/lib/jenkins/tools/hudson.model.JDK/Java_1.5_v22/bin/java, -Xms512m, -Xmx768m, -cp, /var/lib/jenkins/plugins/maven-plugin/WEB-INF/lib/maven-agent-1.3.jar:/var/lib/jenkins/tools/hudson.tasks.Maven_MavenInstallation/Maven_2.2.1/boot/classworlds-1.1.jar, hudson.maven.agent.Main, /var/lib/jenkins/tools/hudson.tasks.Maven_MavenInstallation/Maven_2.2.1, /var/cache/jenkins/war/WEB-INF/lib/remoting-2.28.jar, /var/lib/jenkins/plugins/maven-plugin/WEB-INF/lib/maven-interceptor-1.3.jar, 53755, /var/lib/jenkins/plugins/maven-plugin/WEB-INF/lib/maven2.1-interceptor-1.2.jar] failed
	at hudson.remoting.Channel.call(Channel.java:722)
	at hudson.maven.ProcessCache$MavenProcess.<init>(ProcessCache.java:112)
	at hudson.maven.ProcessCache.get(ProcessCache.java:231)
	at hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.doRun(MavenModuleSetBuild.java:693)
	at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:586)
	at hudson.model.Run.execute(Run.java:1593)
	at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:491)
	at hudson.model.ResourceController.execute(ResourceController.java:88)
	at hudson.model.Executor.run(Executor.java:247)
Caused by: java.lang.ClassFormatError: Failed to load hudson.maven.ProcessCache$GetSystemProperties
	at hudson.remoting.RemoteClassLoader.loadClassFile(RemoteClassLoader.java:291)
	at hudson.remoting.RemoteClassLoader.findClass(RemoteClassLoader.java:229)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
	at java.lang.Class.forName0(Native Method)
	at java.lang.Class.forName(Class.java:242)
	at hudson.remoting.MultiClassLoaderSerializer$Input.resolveClass(MultiClassLoaderSerializer.java:113)
	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1544)
	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1466)
	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1699)
	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
	at hudson.remoting.UserRequest.deserialize(UserRequest.java:182)
	at hudson.remoting.UserRequest.perform(UserRequest.java:98)
	at hudson.remoting.UserRequest.perform(UserRequest.java:48)
	at hudson.remoting.Request$2.run(Request.java:326)
	at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
	at java.util.concurrent.FutureTask.run(FutureTask.java:123)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:651)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:676)
	at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.UnsupportedClassVersionError: Bad version number in .class file
	at java.lang.ClassLoader.defineClass1(Native Method)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:466)
	at hudson.remoting.RemoteClassLoader.loadClassFile(RemoteClassLoader.java:289)
	... 22 more

I have Jenkins 1.525 on Ora Java 6, patch 45, Redhat 6. What I found is problem with Jenkins Maven plugin, when JAR "classes.jar" (at WEB-INF/lib) was compiled only with Java 6 (magic number is "50"). Other 3rd party libs are based on Java 5 (or lower) ...
(Class "hudson.maven.ProcessCache" comes from that JAR "classes.jar")

So maybe will help to rebuild this Jenkins Maven plugin with target Java 5 ???

Is there any activity on this issue? AS we need to build our project with JDK 1.5, we can't upgrade to any newer version of Jenkins.

We're now using Toolchains as suggested. It works fine.

See JENKINS-16920.

As of 1.520, core has moved on to Java6. See https://groups.google.com/forum/#!topic/jenkinsci-dev/LOMtxbR0Elg/discussion for the discussion of this.

To build your Maven project with JDK5, please consider using Maven toolchain, which is developed for this very reason.

I think there is some misunderstanding here, at least from my part. When I read the news about Java 1.5 drop on Jenkins core, I thought it wouldn't affect the forked java process created for each build. Otherwise, there is no reason to allow each build to choose an specific JDK install if Jenkins don't support them all. What am I missing here?

The problem is the JDK 5 API, I think. When using JDK 5, one not only uses a Java 5 compiler, but also the Java 5 framework libraries (collections, etc.). When using a Java 6 compiler emitting Java 5 opcodes, the compiler will not fail compilation if I use Java 6 API - but that is exactly one of the reasons for using a Java 5 JDK for compiling, to have it fail on API that is not supported by JDK/JRE 5.

The Maven Compiler Plugin accepts both source and target constraints. This is what it looks like in our POMs:

<plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.0</version>
        <configuration>
                <source>1.5</source>
                <target>1.5</target>
        </configuration>				
</plugin>

Mine that the "source" constraint affects only language capabilities, such as generics, enhanced loops, @override on interface methods, etc. It does afaik not in any way constrain API use, e.g. "new IOException(Throwable)" not being available in Java 5, but in Java 6.

So look into maven toolchain, as Kohsuke suggests.

Exactly, that's the problem, methods like String.isEmprty() only exists in Java 6 and don't generate errors on Java 1.6 with source = 1.5

Tony, sure, we'll end up using maven toolchain, but what about people that use other builders? We'll also have an extra work to setup toolchain and profiles for jenkins on each job, etc.
Besides that, we have and inconsistency here. We can create a Java 5 runtime to run our jobs, but it doesn't work. It doesn't make sense for me.

Toolchains appears to be a good option, but it doesn't appear to be very portable - in particular, it doesn't seem to interface with the Jenkins auto-download functionality. A Jenkins plugin to generate the "toolchains.xml" depending on the JDKs available to Jenkins might remedy that. Still, for local builds, I guess every developer would need to maintain such a file for himself/herself. Again, this might be worked around by configuring the toolchains within a profile which gets activated only when a developer desires (or when a Jenkins build is detected). OTH, however, much more inconvenient than just selecting JDK X from the drop down in Jenkins.

You seem to have mistaken me for Jenkins Tech support. It was extra work for my organisation to put in place a workround when this change was rolled out with little notice. In my view this change should have been explicitly documented in the release notes for version 1.520; a post hoc reference to the dev list is no help to admins like me when evaluating the risk/cost of upgrading the core Jenkins version. It's already difficult enough to ride herd on an open source project and dozens of subtly interacting plugins. My comments here are only intended to clarify the issue and to document a workround for one of the simplest cases.

Tony, at least I didn't mean to treat anybody as tech support. My comments were mostly meant to document what is not covered by the workarounds that have been suggested here, so people that may try follow they may be less surprised about the effects. The last comment was also trying to hint at potential value in integrating the toolchains plugin with Jenkins - without any expectation that anybody would do this any time (soon). There seems to be a general movement towards JDK 6 from the projects that I see. Personally, I'm using the approach compiling with a JDK6 compiler but target/source set to 5, because there are is neither sufficient pressure nor sufficient free resources to switch to toolchains or anything else.

That said: if somebody reads this and feels motivated to build some Jenkins plugin for the maven-toolchains-plugin: it might make some people happy, at least for another while, and probably again the next time such a switch comes up (e.g. from JDK 6 to 7)