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

Jenkins 1.518 causes Java 5 Maven builds to fail

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Critical Critical
    • maven-plugin
    • Ubuntu Linux 12.04 LTS
      Slave.jar running under Java 7
      Project: Maven 3.0.4, JDK 5 Update 22

      After the upgrade from Jenkins 1.515 to Jenkins 1.518 one of our Maven projects failed due to a ClassFormatException:

      23:13:30 [JENKINS] Archiving site from /export/build/jenkins-slave/workspace/xxx-nightly-trunk/target/site to /export/build/jenkins/jobs/xxx-nightly-trunk/site
      23:13:37 java.lang.reflect.InvocationTargetException
      23:13:37 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      23:13:37 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
      23:13:37 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      23:13:37 	at java.lang.reflect.Method.invoke(Method.java:592)
      23:13:37 	at org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329)
      23:13:37 	at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239)
      23:13:37 	at org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:158)
      23:13:37 	at hudson.maven.Maven3Builder.call(Maven3Builder.java:100)
      23:13:37 	at hudson.maven.Maven3Builder.call(Maven3Builder.java:66)
      23:13:37 	at hudson.remoting.UserRequest.perform(UserRequest.java:118)
      23:13:37 	at hudson.remoting.UserRequest.perform(UserRequest.java:48)
      23:13:37 	at hudson.remoting.Request$2.run(Request.java:326)
      23:13:37 	at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
      23:13:37 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
      23:13:37 	at java.util.concurrent.FutureTask.run(FutureTask.java:123)
      23:13:37 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:651)
      23:13:37 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:676)
      23:13:37 	at java.lang.Thread.run(Thread.java:595)
      23:13:37 Caused by: java.lang.ClassFormatError: Failed to load jnr.ffi.mapper.FunctionMapper
      23:13:37 	at hudson.remoting.RemoteClassLoader.loadClassFile(RemoteClassLoader.java:193)
      23:13:37 	at hudson.remoting.RemoteClassLoader.findClass(RemoteClassLoader.java:144)
      23:13:37 	at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
      23:13:37 	at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
      23:13:37 	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
      23:13:37 	at hudson.os.PosixAPI.jnr(PosixAPI.java:30)
      23:13:37 	at hudson.util.IOUtils.mode(IOUtils.java:125)
      23:13:37 	at hudson.util.io.TarArchiver.visit(TarArchiver.java:102)
      23:13:37 	at hudson.util.DirScanner$Glob.scan(DirScanner.java:133)
      23:13:37 	at hudson.FilePath.writeToTar(FilePath.java:1979)
      23:13:37 	at hudson.FilePath.copyRecursiveTo(FilePath.java:1905)
      23:13:37 	at hudson.FilePath.copyRecursiveTo(FilePath.java:1832)
      23:13:37 	at hudson.maven.reporters.MavenSiteArchiver.postExecute(MavenSiteArchiver.java:82)
      23:13:37 	at hudson.maven.Maven3Builder$MavenExecutionListener.recordMojoEnded(Maven3Builder.java:453)
      23:13:37 	at hudson.maven.Maven3Builder$MavenExecutionListener.mojoSucceeded(Maven3Builder.java:435)
      23:13:37 	at org.apache.maven.lifecycle.internal.DefaultExecutionEventCatapult.fire(DefaultExecutionEventCatapult.java:87)
      23:13:37 	at org.apache.maven.lifecycle.internal.DefaultExecutionEventCatapult.fire(DefaultExecutionEventCatapult.java:42)
      23:13:37 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:228)
      23:13:37 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
      23:13:37 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
      23:13:37 	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
      23:13:37 	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
      23:13:37 	at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
      23:13:37 	at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
      23:13:37 	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
      23:13:37 	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
      23:13:37 	at org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:79)
      23:13:37 	... 18 more
      23:13:37 Caused by: java.lang.UnsupportedClassVersionError: Bad version number in .class file
      23:13:37 	at java.lang.ClassLoader.defineClass1(Native Method)
      23:13:37 	at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
      23:13:37 	at java.lang.ClassLoader.defineClass(ClassLoader.java:466)
      23:13:37 	at hudson.remoting.RemoteClassLoader.loadClassFile(RemoteClassLoader.java:191)
      23:13:37 	... 44 more
      23:13:37 channel stopped
      23:13:38 ERROR: Failed to parse POMs
      

      The issue can be found in the call stack:
      The Jenkins slave calls the Maven launcher and and the Maven launcher does a callback into the Jenkins code to perform some IO operations. For those operations, the jnr-ffi library is used and this has been compiled on the 8th of June under OpenJDK 6 and under Oracle JDK 7:
      https://travis-ci.org/jnr/jnr-ffi
      The pom.xml of the library has no compiler plugin configuration and thus creates code for whatever JDK it runs on (Java 6 class version 50) and I assume that this new version of the library has been pulled in between 1.516 and 1.518 of Jenkins.

      That means this new version of the jnr-ffi library drops Java 5 support for certain Maven builds.

          [JENKINS-18403] Jenkins 1.518 causes Java 5 Maven builds to fail

          Michael Rumpf created issue -

          Georg Sash added a comment -

          Guys, it is a constantly reoccurring issue that non-Java5 compatible class files get leaked into the Jenkins distribution. Is it so hard to add a test case that explicitly checks if Java5 support is still intact??

          Georg Sash added a comment - Guys, it is a constantly reoccurring issue that non-Java5 compatible class files get leaked into the Jenkins distribution. Is it so hard to add a test case that explicitly checks if Java5 support is still intact??

          Michael Rumpf added a comment -

          Our current workaround is to set the Maven compiler via command line:
          -Dmaven.compiler.executable=<JDK5-javac>

          Michael Rumpf added a comment - Our current workaround is to set the Maven compiler via command line: -Dmaven.compiler.executable=<JDK5-javac>

          Jesse Glick added a comment -

          The use of a 1.6-based copy of JNR here is almost irrelevant since https://github.com/jenkinsci/jenkins/commit/3431a7cba4a8c73d975ae7db69892a2eb473b5d0 in 1.520 means that all Jenkins code requires Java 6+ to run.

          Jesse Glick added a comment - The use of a 1.6-based copy of JNR here is almost irrelevant since https://github.com/jenkinsci/jenkins/commit/3431a7cba4a8c73d975ae7db69892a2eb473b5d0 in 1.520 means that all Jenkins code requires Java 6+ to run.
          Jesse Glick made changes -
          Link New: This issue is related to JENKINS-16920 [ JENKINS-16920 ]
          Jesse Glick made changes -
          Labels New: regression

          Jesse Glick added a comment -
          diff --git a/maven-plugin/src/main/java/hudson/maven/ProcessCache.java b/maven-plugin/src/main/java/hudson/maven/ProcessCache.java
          index bad99b0..cdabd33 100644
          --- a/maven-plugin/src/main/java/hudson/maven/ProcessCache.java
          +++ b/maven-plugin/src/main/java/hudson/maven/ProcessCache.java
          @@ -105,6 +105,8 @@ public final class ProcessCache {
                       this.parent = parent;
                       this.mavenOpts = mavenOpts;
                       this.channel = np.channel;
          +            short JDK5 = 5;
          +            channel.setMaximumBytecodeLevel(JDK5);
                       this.proc = np.proc;
                       this.installation = installation;
                       this.jdk = jdk;
          diff --git a/pom.xml b/pom.xml
          index 4c2ed2e..023fe37 100644
          --- a/pom.xml
          +++ b/pom.xml
          @@ -175,7 +175,7 @@ THE SOFTWARE.
                 <dependency>
                   <groupId>org.jenkins-ci.main</groupId>
                   <artifactId>remoting</artifactId>
          -        <version>2.28</version>
          +        <version>2.29-SNAPSHOT</version>
                 </dependency>
           
                 <dependency>
          

          shows how to reproduce the problem without even having JDK 5.

          Jesse Glick added a comment - diff --git a/maven-plugin/src/main/java/hudson/maven/ProcessCache.java b/maven-plugin/src/main/java/hudson/maven/ProcessCache.java index bad99b0..cdabd33 100644 --- a/maven-plugin/src/main/java/hudson/maven/ProcessCache.java +++ b/maven-plugin/src/main/java/hudson/maven/ProcessCache.java @@ -105,6 +105,8 @@ public final class ProcessCache { this.parent = parent; this.mavenOpts = mavenOpts; this.channel = np.channel; + short JDK5 = 5; + channel.setMaximumBytecodeLevel(JDK5); this.proc = np.proc; this.installation = installation; this.jdk = jdk; diff --git a/pom.xml b/pom.xml index 4c2ed2e..023fe37 100644 --- a/pom.xml +++ b/pom.xml @@ -175,7 +175,7 @@ THE SOFTWARE. <dependency> <groupId>org.jenkins-ci.main</groupId> <artifactId>remoting</artifactId> - <version>2.28</version> + <version>2.29-SNAPSHOT</version> </dependency> <dependency> shows how to reproduce the problem without even having JDK 5.

          As of 1.520, core has moved on to Java6, so currently this is expected.

          To quote the changelog, "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."

          Kohsuke Kawaguchi added a comment - As of 1.520, core has moved on to Java6, so currently this is expected. To quote the changelog, "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."

          Jesse Glick added a comment -

          The pom.xml of the library has no compiler plugin configuration and thus creates code for whatever JDK it runs on (Java 6 class version 50)

          Not true; the JNR POM specifies <maven.compiler.target>1.6</maven.compiler.target> as of 1.0.0.

          (The Maven compiler plugin always uses a deterministic source/target level, regardless of the JDK used to run Maven. If unspecified, it currently defaults to JDK 5.)

          Jesse Glick added a comment - The pom.xml of the library has no compiler plugin configuration and thus creates code for whatever JDK it runs on (Java 6 class version 50) Not true; the JNR POM specifies <maven.compiler.target>1.6</maven.compiler.target> as of 1.0.0. (The Maven compiler plugin always uses a deterministic source/target level, regardless of the JDK used to run Maven. If unspecified, it currently defaults to JDK 5.)

          Jesse Glick added a comment -

          While there is no current plan to fix this in the sense of restoring the ability to run Maven on JDK 5, I will investigate making the plugin behave more gracefully when JDK 5 is selected for the project.

          Jesse Glick added a comment - While there is no current plan to fix this in the sense of restoring the ability to run Maven on JDK 5, I will investigate making the plugin behave more gracefully when JDK 5 is selected for the project.
          Jesse Glick made changes -
          Assignee New: Jesse Glick [ jglick ]
          Labels Original: regression New: jdk regression

            jglick Jesse Glick
            mirumpf Michael Rumpf
            Votes:
            3 Vote for this issue
            Watchers:
            11 Start watching this issue

              Created:
              Updated:
              Resolved: