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

remoting-2.46.jar breaks JDK 5 Maven builds

XMLWordPrintable

      Hey community,

      after the last upgrade (I guess it was from Jenkins 1.551) to Jenkins 1.584 we encounter serious problems with our legacy Java5 Maven builds.
      When Jenkins calls the Maven plugin (right after "Parsing poms") the build crashes with the following stacktrace:

      Parsing POMs
Modules changed, recalculating dependency graph
[my-maven-project] $ /var/apphome/162_cipbld/jdk_1.5_latest/bin/java -Xms64m -Xmx256m -XX:PermSize=64m -XX:MaxPermSize=256m -cp /var/apphome/162_cipbld/.jenkins/plugins/maven-plugin/WEB-INF/lib/maven3-agent-1.5.jar:/var/apphome/162_cipbld/apache-maven-3.0.4/boot/plexus-classworlds-2.4.jar org.jvnet.hudson.maven3.agent.Maven3Main /var/apphome/162_cipbld/apache-maven-3.0.4 /var/apphome/162_cipbld/162_cipbld-0/webapps/jenkins/WEB-INF/lib/remoting-2.46.jar /var/apphome/162_cipbld/.jenkins/plugins/maven-plugin/WEB-INF/lib/maven3-interceptor-1.5.jar /var/apphome/162_cipbld/.jenkins/plugins/maven-plugin/WEB-INF/lib/maven3-interceptor-commons-1.5.jar 58566
Exception in thread "main" 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.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
	at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
	at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
	at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClassFromSelf(ClassRealm.java:386)
	at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:42)
	at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:244)
	at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:230)
	at org.jvnet.hudson.maven3.agent.Maven3Main.main(Maven3Main.java:135)
	at org.jvnet.hudson.maven3.agent.Maven3Main.main(Maven3Main.java:64)
[EnvInject] - Injecting environment variables from a build step.
[EnvInject] - Injecting as environment variables the properties file path '/path/to/my.properties'
[EnvInject] - Variables injected successfully.
ERROR: Failed to parse POMs
java.net.SocketException: Connection reset
	at java.net.SocketInputStream.read(SocketInputStream.java:168)
	at java.io.FilterInputStream.read(FilterInputStream.java:116)
	at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
	at java.io.BufferedInputStream.read(BufferedInputStream.java:237)
	at hudson.remoting.ChannelBuilder.negotiate(ChannelBuilder.java:198)
	at hudson.remoting.Channel.<init>(Channel.java:418)
	at hudson.remoting.Channel.<init>(Channel.java:397)
	at hudson.remoting.Channel.<init>(Channel.java:393)
	at hudson.remoting.Channel.<init>(Channel.java:382)
	at hudson.remoting.Channel.<init>(Channel.java:374)
	at hudson.remoting.Channel.<init>(Channel.java:366)
	at hudson.slaves.Channels$1.<init>(Channels.java:70)
	at hudson.slaves.Channels.forProcess(Channels.java:70)
	at hudson.maven.AbstractMavenProcessFactory.newProcess(AbstractMavenProcessFactory.java:280)
	at hudson.maven.ProcessCache.get(ProcessCache.java:235)
	at hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.doRun(MavenModuleSetBuild.java:759)
	at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:533)
	at hudson.model.Run.execute(Run.java:1754)
	at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:529)
	at hudson.model.ResourceController.execute(ResourceController.java:89)
	at hudson.model.Executor.run(Executor.java:240)
Email was triggered for: Failure - Any

      I figured out that the only difference between succeeding and failing builds was the version of remoting.jar. The new Jenkins version ships with version 2.46. When I stopped Tomcat and exchanged the remoting-2.46.jar with remoting-2.44.jar the builds work again.

      Could you please investigate this as it is crucial to us that the Java5 builds are still stable to build?

      Thanks!

        1. old-jdk-JENKINS-25272.zip
          2 kB

          [JENKINS-25272] remoting-2.46.jar breaks JDK 5 Maven builds

          Stefan Strobel created issue -

          Daniel Beck added a comment -

          Appears to be caused by https://github.com/jenkinsci/remoting/commit/846ce5f22fdd9c15271ea4e25e672bc7c5a858e8

          Workaround would probably be to compile on more recent JDK (with lower target version), and/or not use the Maven Project type (Freestyle project with Maven build step instead).

          Reducing priority due to workarounds and the apparent deliberate nature of this change.

          Daniel Beck added a comment - Appears to be caused by https://github.com/jenkinsci/remoting/commit/846ce5f22fdd9c15271ea4e25e672bc7c5a858e8 Workaround would probably be to compile on more recent JDK (with lower target version), and/or not use the Maven Project type (Freestyle project with Maven build step instead). Reducing priority due to workarounds and the apparent deliberate nature of this change.
          Daniel Beck made changes -
          Priority Original: Blocker [ 1 ] New: Major [ 3 ]
          Daniel Beck made changes -
          Link New: This issue is duplicated by JENKINS-25325 [ JENKINS-25325 ]
          Andreas Mandel made changes -
          Labels Original: Java5 Maven UnsupportedClassVersionError remoting New: Java5 Maven UnsupportedClassVersionError lts-candidate remoting

          Andreas Mandel added a comment -

          Compiling with a different JDK with different API is not really an option for building productive release code (ok, it should not use such a outdated JDK either). Unfortunately I also use the maven release plugin a lot, this can afaik not be emulated easily by a freestyle job.

          For me the severity is actually blocker because I have a whole bunch of these jobs. The fix of JENKINS-18403 from jglick sounded like a reliable way to support older JDKs without the need that the Jenkins code itself needs to be 1.4 compatible forever.

          Andreas Mandel added a comment - Compiling with a different JDK with different API is not really an option for building productive release code (ok, it should not use such a outdated JDK either). Unfortunately I also use the maven release plugin a lot, this can afaik not be emulated easily by a freestyle job. For me the severity is actually blocker because I have a whole bunch of these jobs. The fix of JENKINS-18403 from jglick sounded like a reliable way to support older JDKs without the need that the Jenkins code itself needs to be 1.4 compatible forever.
          Andreas Mandel made changes -
          Labels Original: Java5 Maven UnsupportedClassVersionError lts-candidate remoting New: Java5 Maven UnsupportedClassVersionError lts lts-candidate regression remoting
          Andreas Mandel made changes -
          Link New: This issue is blocking JENKINS-18403 [ JENKINS-18403 ]

          Jesse Glick added a comment - - edited

          The automated workaround of JENKINS-18403 was merely to run Maven in Java 6+ but pass -Dmaven.compiler.fork -Dmaven.compiler.executable=…/jdk5/bin/javac -Djvm=…/jdk5/bin/java, which you can configure your project to do to begin with. It was not a true fix; you cannot run Maven itself in Java 5 if you are using the Maven Project plugin.

          That fix did catch UnsupportedClassVersionError, but perhaps it is now thrown at a different time. Needs investigation.

          with different API

          See animal-sniffer-maven-plugin.

          Jesse Glick added a comment - - edited The automated workaround of JENKINS-18403 was merely to run Maven in Java 6+ but pass -Dmaven.compiler.fork -Dmaven.compiler.executable=…/jdk5/bin/javac -Djvm=…/jdk5/bin/java , which you can configure your project to do to begin with. It was not a true fix; you cannot run Maven itself in Java 5 if you are using the Maven Project plugin. That fix did catch UnsupportedClassVersionError , but perhaps it is now thrown at a different time. Needs investigation. with different API See animal-sniffer-maven-plugin .

          Andreas Mandel added a comment -

          Thanks for the feedback. Actually I even use a IBM JDK to get the 'correct' compile results, so I don't think using a different compiler version and checking the used API is sufficient here.

          The problem in setting the JDK environment during the build is that normally the JDKs are managed by Jenkins and not by the Build Job, so it is not easy to know the correct JAVA_HOME (especially on a not jet selected build node) to be set. Your fix solved this in a elegant way (IMHO). It looks that for some reason your switching magic does not kick in or kicks in to late.

          Andreas Mandel added a comment - Thanks for the feedback. Actually I even use a IBM JDK to get the 'correct' compile results, so I don't think using a different compiler version and checking the used API is sufficient here. The problem in setting the JDK environment during the build is that normally the JDKs are managed by Jenkins and not by the Build Job, so it is not easy to know the correct JAVA_HOME (especially on a not jet selected build node) to be set. Your fix solved this in a elegant way (IMHO). It looks that for some reason your switching magic does not kick in or kicks in to late.

            jglick Jesse Glick
            chemiker Stefan Strobel
            Votes:
            6 Vote for this issue
            Watchers:
            11 Start watching this issue

              Created:
              Updated:
              Resolved: