Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-18592

JDK jdk1.5.0_12 builds fail with java.lang.UnsupportedClassVersionError since upgrade to Jenkins 1.520

    • Icon: Bug Bug
    • Resolution: Won't Fix
    • Icon: Blocker Blocker
    • maven-plugin
    • None
    • Windows Server 2008
      Jenkins 1.520 (en 1.521) als windows service behind Apache 2.2.19
      JDK jdk1.7.0_09

      projects build with jdk1.5.0_12

      Projects build with jdk1.5.0_12 fail since the upgrade to Jenkins 1.520

      <===[JENKINS REMOTING CAPACITY]===>channel started
      erreicht: 902
      ERROR: Failed to parse POMs
      java.io.IOException: Remote call on Channel to Maven [D:\apps\Java\jdk1.5.0_12/bin/java, -cp, D:\apps\Jenkins\plugins\maven-plugin\WEB-INF\lib\maven-agent-1.3.jar;D:\apps\Maven\apache-maven-2.2.1\boot\classworlds-1.1.jar, hudson.maven.agent.Main, D:\apps\Maven\apache-maven-2.2.1, D:\apps\Jenkins\war\WEB-INF\lib\remoting-2.24.jar, D:\apps\Jenkins\plugins\maven-plugin\WEB-INF\lib\maven-interceptor-1.3.jar, 51928, D:\apps\Jenkins\plugins\maven-plugin\WEB-INF\lib\maven2.1-interceptor-1.2.jar] failed
      at hudson.remoting.Channel.call(Channel.java:731)
      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:694)
      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:306)
      at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
      at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
      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:650)
      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
      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:620)
      at java.lang.ClassLoader.defineClass(ClassLoader.java:465)
      at hudson.remoting.RemoteClassLoader.loadClassFile(RemoteClassLoader.java:289)
      ... 22 more

          [JENKINS-18592] JDK jdk1.5.0_12 builds fail with java.lang.UnsupportedClassVersionError since upgrade to Jenkins 1.520

          Tony Sweeney added a comment - - edited

          The problems is that some of the hudson.maven classes used by the Maven plugin have been compiled with Java 6, so if you specify that your Maven job is to run with a Java 5 compiler (because you want to generate Java 5 code), those classes won't load as seen in the stack traces above. For us the workround was to run the job under Java 6, but pass additional parameters to the Maven task, telling it to emit only Java 5 opcodes (in our case because we are compiling a plugin for JBoss 4). Ant builds are unaffected and continue to run quite happily with Java 5.

          Tony Sweeney added a comment - - edited The problems is that some of the hudson.maven classes used by the Maven plugin have been compiled with Java 6, so if you specify that your Maven job is to run with a Java 5 compiler (because you want to generate Java 5 code), those classes won't load as seen in the stack traces above. For us the workround was to run the job under Java 6, but pass additional parameters to the Maven task, telling it to emit only Java 5 opcodes (in our case because we are compiling a plugin for JBoss 4). Ant builds are unaffected and continue to run quite happily with Java 5.

          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.

          Richard Eckart de Castilho added a comment - 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.

          Tony Sweeney added a comment -

          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>
          

          Tony Sweeney added a comment - 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.

          Richard Eckart de Castilho added a comment - 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.

          Tony Sweeney added a comment -

          So look into maven toolchain, as Kohsuke suggests.

          Tony Sweeney added a comment - 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

          Bruno Medeiros added a comment - 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.

          Bruno Medeiros added a comment - 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.

          Richard Eckart de Castilho added a comment - 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.

          Tony Sweeney added a comment -

          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 Sweeney added a comment - 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)

          Richard Eckart de Castilho added a comment - 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)

            kohsuke Kohsuke Kawaguchi
            bverbrug Bob Verbrugge
            Votes:
            9 Vote for this issue
            Watchers:
            14 Start watching this issue

              Created:
              Updated:
              Resolved: