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

    XMLWordPrintable

Details

    • Bug
    • Status: Resolved (View Workflow)
    • Blocker
    • Resolution: Fixed
    • core
    • None
    • SunOS 5.10, JDK5

    Description

      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.

      Attachments

        Issue Links

          Activity

            drulli Ulli Hafner added a comment - - edited

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

            drulli Ulli Hafner added a comment - - edited Hmm, didn't we agree to move to Java 1.6 quite some time ago?
            kutzi 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 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 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 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.
            jglick 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.

            jglick 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.
            lweller 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.

            lweller 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.

            People

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

              Dates

                Created:
                Updated:
                Resolved: