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

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Blocker
    • Resolution: Won't Fix
    • Component/s: maven-plugin
    • Labels:
      None
    • Environment:
      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
    • Similar Issues:

      Description

      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

        Attachments

          Issue Links

            Activity

            Hide
            brunojcm 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

            Show
            brunojcm 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
            Hide
            brunojcm 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.

            Show
            brunojcm 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.
            Hide
            rec 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.

            Show
            rec 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.
            Hide
            tony_sweeney 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.

            Show
            tony_sweeney 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.
            Hide
            rec 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)

            Show
            rec 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)

              People

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

                Dates

                Created:
                Updated:
                Resolved: