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

Migrating to Jenkins 1.500 break JDK5 compatibility - UnsupportedClassVersionError: Bad version number in .class file

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Blocker Blocker
    • core
    • None
    • SunOS 5.10, JDK5

      The upgrade of the Commons Codec lib from 1.4 to 1.7 with Jenkins 1.500 break the compatibility to build with JDK5.

      The build fails with

      [INFO] ------------------------------------------------------------------------
      [ERROR] FATAL ERROR
      [INFO] ------------------------------------------------------------------------
      [INFO] Failed to load org.apache.commons.codec.DecoderException
      Bad version number in .class file
      [INFO] ------------------------------------------------------------------------
      [INFO] Trace
      java.lang.ClassFormatError: Failed to load org.apache.commons.codec.DecoderException
      at hudson.remoting.RemoteClassLoader.loadClassFile(RemoteClassLoader.java:193)
      at hudson.remoting.RemoteClassLoader.findClass(RemoteClassLoader.java:144)
      at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
      at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
      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:191)

      Replacing Commons Codec 1.7 with 1.6 seems to fix the problem.
      On the Commons Codec site (http://commons.apache.org/codec/) the following compatibility notes can be found:

      Codec 1.7 requires Java 1.6
      Codec 1.6 requires Java 1.5
      Codec 1.5 requires Java 1.4

      So please downgrade to Commons Codec 1.6 if possible.

          [JENKINS-16554] Migrating to Jenkins 1.500 break JDK5 compatibility - UnsupportedClassVersionError: Bad version number in .class file

          Marco Rothe added a comment -

          Seems to be caused by the same dependency upgrade

          Marco Rothe added a comment - Seems to be caused by the same dependency upgrade

          Marco Rothe added a comment -

          This seems to be the cause of the problem

          Marco Rothe added a comment - This seems to be the cause of the problem

          Code changed in jenkins
          User: Christoph Kutzinski
          Path:
          changelog.html
          core/pom.xml
          http://jenkins-ci.org/commit/jenkins/41fc8a10bb8eb0e7b106e25eb643481376ac1829
          Log:
          [FIXED JENKINS-16554] Restored Java 5 compatibility by downgrading to commons codec 1.6


          You received this message because you are subscribed to the Google Groups "Jenkins Commits" group.
          To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-commits+unsubscribe@googlegroups.com.
          For more options, visit https://groups.google.com/groups/opt_out.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Christoph Kutzinski Path: changelog.html core/pom.xml http://jenkins-ci.org/commit/jenkins/41fc8a10bb8eb0e7b106e25eb643481376ac1829 Log: [FIXED JENKINS-16554] Restored Java 5 compatibility by downgrading to commons codec 1.6 – You received this message because you are subscribed to the Google Groups "Jenkins Commits" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-commits+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out .

          dogfood added a comment -

          Integrated in jenkins_main_trunk #2239
          [FIXED JENKINS-16554] Restored Java 5 compatibility by downgrading to commons codec 1.6 (Revision 41fc8a10bb8eb0e7b106e25eb643481376ac1829)

          Result = SUCCESS
          Christoph Kutzinski : 41fc8a10bb8eb0e7b106e25eb643481376ac1829
          Files :

          • core/pom.xml
          • changelog.html

          dogfood added a comment - Integrated in jenkins_main_trunk #2239 [FIXED JENKINS-16554] Restored Java 5 compatibility by downgrading to commons codec 1.6 (Revision 41fc8a10bb8eb0e7b106e25eb643481376ac1829) Result = SUCCESS Christoph Kutzinski : 41fc8a10bb8eb0e7b106e25eb643481376ac1829 Files : core/pom.xml changelog.html

          Ulli Hafner added a comment - - edited

          Hmm, didn't we agree to move to Java 1.6 quite some time ago?

          Ulli Hafner added a comment - - edited Hmm, didn't we agree to move to Java 1.6 quite some time ago?

          kutzi added a comment -

          I've found a discussion on the dev list from September which didn't seem to have come to a real conclusion.
          There were some concerns that Maven jobs running on Java 5 would maybe not work anymore if the core is compiled which target 1.6

          Also https://wiki.jenkins-ci.org/display/JENKINS/Meet+Jenkins still mentions Java 1.5 as minimum requirement.

          kutzi added a comment - I've found a discussion on the dev list from September which didn't seem to have come to a real conclusion. There were some concerns that Maven jobs running on Java 5 would maybe not work anymore if the core is compiled which target 1.6 Also https://wiki.jenkins-ci.org/display/JENKINS/Meet+Jenkins still mentions Java 1.5 as minimum requirement.

          Marco Rothe added a comment -

          In our case some maven jobs (which run on/required JDK5) fail, not the jenkins server (run on Java7) or the slaves (run on Java6).
          So it seems to me that the "core" classloader is not so isolated from the build classloader that maven builds on JDK5 can cooexists with Java6 only jars at the slave level.

          Marco Rothe added a comment - In our case some maven jobs (which run on/required JDK5) fail, not the jenkins server (run on Java7) or the slaves (run on Java6). So it seems to me that the "core" classloader is not so isolated from the build classloader that maven builds on JDK5 can cooexists with Java6 only jars at the slave level.

          Jesse Glick added a comment -

          @kutzi thanks for dealing with this! Was on my to-do list (or at least my list of things to bring to Kohsuke’s attention).

          Whether Java 5 should still be supported for Jenkins artifacts is an interesting conversation (involving also considerations of less common operating systems, and old Macs) but should better be kept on jenkinsci-dev. AFAIK there has not yet been consensus to drop Java 5 compatibility. @marco_rothe’s finding probably has to do not with class loaders but with the Jenkins agent injected into a Maven build to track it.

          Probably we need to be running selenium-tests on Java 5.

          Jesse Glick added a comment - @kutzi thanks for dealing with this! Was on my to-do list (or at least my list of things to bring to Kohsuke’s attention). Whether Java 5 should still be supported for Jenkins artifacts is an interesting conversation (involving also considerations of less common operating systems, and old Macs) but should better be kept on jenkinsci-dev. AFAIK there has not yet been consensus to drop Java 5 compatibility. @marco_rothe’s finding probably has to do not with class loaders but with the Jenkins agent injected into a Maven build to track it. Probably we need to be running selenium-tests on Java 5.

          Lucien Weller added a comment -

          as workarround until Jenkin-1.501 is released I just replaced commons-condec-1.7 lib by commons-coded-1.6 and now every thing works fine.

          Lucien Weller added a comment - as workarround until Jenkin-1.501 is released I just replaced commons-condec-1.7 lib by commons-coded-1.6 and now every thing works fine.

            kutzi kutzi
            marco_rothe Marco Rothe
            Votes:
            1 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated:
              Resolved: