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

Jenkins 2.54 causes java.lang.UnsupportedClassVersionError

    • Icon: Bug Bug
    • Resolution: Not A Defect
    • Icon: Blocker Blocker
    • core
    • None
    • Windows 7 SP1, 64-bit (Jenkins as Windows Service)
      Jenkins 2.54 (Updated from 2.53)
      Java 1.8.0 121-b13

      After updating from Jenkins 2.53 to Jenkins 2.54 the Windows service appears to start successfully but the error log reports an InvocationTargetException caused by an UnsupportedClassVersionError: jenkins/util/SystemProperties : Unsupported major.minor version 52.0

      Navigating to the Jenkins homepage gives an error code 503.

      Reverting to Jenkins 2.53 fixes the issue.

      The jenkins.err file is attached, but the stack trace is as follows:

      WARNING: Failed startup of context w.@68be28{/,file:/C:/Program%20Files%20(x86)/Jenkins/war/,STARTING}{C:\Program Files (x86)\Jenkins\war}
      java.lang.reflect.InvocationTargetException
      	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
      	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
      	at java.lang.reflect.Method.invoke(Unknown Source)
      	at org.eclipse.jetty.webapp.IterativeDescriptorProcessor.visit(IterativeDescriptorProcessor.java:85)
      	at org.eclipse.jetty.webapp.IterativeDescriptorProcessor.process(IterativeDescriptorProcessor.java:72)
      	at org.eclipse.jetty.webapp.MetaData.resolve(MetaData.java:408)
      	at org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1340)
      	at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:741)
      	at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:505)
      	at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
      	at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:132)
      	at org.eclipse.jetty.server.Server.start(Server.java:387)
      	at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:114)
      	at org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:61)
      	at org.eclipse.jetty.server.Server.doStart(Server.java:354)
      	at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
      	at winstone.Launcher.<init>(Launcher.java:152)
      	at winstone.Launcher.main(Launcher.java:352)
      	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
      	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
      	at java.lang.reflect.Method.invoke(Unknown Source)
      	at Main._main(Main.java:264)
      	at Main.main(Main.java:112)
      Caused by: java.lang.UnsupportedClassVersionError: jenkins/util/SystemProperties : Unsupported major.minor version 52.0
      	at java.lang.ClassLoader.defineClass1(Native Method)
      	at java.lang.ClassLoader.defineClass(Unknown Source)
      	at java.security.SecureClassLoader.defineClass(Unknown Source)
      	at java.net.URLClassLoader.defineClass(Unknown Source)
      	at java.net.URLClassLoader.access$100(Unknown Source)
      	at java.net.URLClassLoader$1.run(Unknown Source)
      	at java.net.URLClassLoader$1.run(Unknown Source)
      	at java.security.AccessController.doPrivileged(Native Method)
      	at java.net.URLClassLoader.findClass(Unknown Source)
      	at org.eclipse.jetty.webapp.WebAppClassLoader.findClass(WebAppClassLoader.java:510)
      	at org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:441)
      	at org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:403)
      	at org.eclipse.jetty.server.handler.ContextHandler.loadClass(ContextHandler.java:1583)
      	at org.eclipse.jetty.webapp.StandardDescriptorProcessor.visitListener(StandardDescriptorProcessor.java:1956)
      	... 25 more
      

      Our jenkins.xml configuration file is also attached.

          [JENKINS-43492] Jenkins 2.54 causes java.lang.UnsupportedClassVersionError

          Oleg Nenashev added a comment -

          Closing as "Not a defect", please reopen if you disagree

          Oleg Nenashev added a comment - Closing as "Not a defect", please reopen if you disagree

          I think we've figured it out.

          When we first started using Jenkins we installed it using the Windows installer, which installed Jenkins as a service. This installed its own version of Java as well and it has been using that all this time to run Jenkins:

          "C:\Program Files (x86)\Jenkins\jre\bin\java.exe" -version
          java version "1.7.0_25"
          Java(TM) SE Runtime Environment (build 1.7.0_25-b17)
          Java HotSpot(TM) Client VM (build 23.25-b01, mixed mode)
          

          This was a bit of a surprise for us - we'd been updating Java regularly, the "java -version" command gave us version 8, and we never realised that Jenkins was using its own version of Java. I think that this is why Jenkins 2.54 was failing even though we had Java version 8 installed on our server.

          Since the issue is not with Jenkins itself I am satisfied that this issue is "Not a defect". Though I am a bit concerned that if Jenkins from the Windows Installer is using its own version of Java it could leave a security hole. Maybe this is something that's worth looking into?

          Thanks for pointing us in the right direction Oleg, we really appreciate your help and patience!

          Ciaran McCarthy added a comment - I think we've figured it out. When we first started using Jenkins we installed it using the Windows installer, which installed Jenkins as a service. This installed its own version of Java as well and it has been using that all this time to run Jenkins: "C:\Program Files (x86)\Jenkins\jre\bin\java.exe" -version java version "1.7.0_25" Java(TM) SE Runtime Environment (build 1.7.0_25-b17) Java HotSpot(TM) Client VM (build 23.25-b01, mixed mode) This was a bit of a surprise for us - we'd been updating Java regularly, the "java -version" command gave us version 8, and we never realised that Jenkins was using its own version of Java. I think that this is why Jenkins 2.54 was failing even though we had Java version 8 installed on our server. Since the issue is not with Jenkins itself I am satisfied that this issue is "Not a defect". Though I am a bit concerned that if Jenkins from the Windows Installer is using its own version of Java it could leave a security hole. Maybe this is something that's worth looking into? Thanks for pointing us in the right direction Oleg, we really appreciate your help and patience!

          Oleg Nenashev added a comment -

          Created JENKINS-43499 to check all installers

          Oleg Nenashev added a comment - Created JENKINS-43499 to check all installers

          The debian packages also do not check Java Version and give no hint while updating.

           

          BTW: http://semver.org/ would be very nice.

          Alexander Opitz added a comment - The debian packages also do not check Java Version and give no hint while updating.   BTW: http://semver.org/ would be very nice.

          Oleg Nenashev added a comment -

          Debian packaging is JENKINS-43495.
          Regarding SemVer, unfortunately Jenkins project works slightly differently. Even though, there was no API compatibility changes

          Oleg Nenashev added a comment - Debian packaging is JENKINS-43495 . Regarding SemVer, unfortunately Jenkins project works slightly differently. Even though, there was no API compatibility changes

          Sascha Szott added a comment -

          Please update the control file in the 2.54 deb package since it currently does not reflect the Java 1.8 dependency:

          Depends: daemon, adduser, procps, psmisc, net-tools, default-jre-headless (>= 2:1.7) | java7-runtime-headless
          

          Sascha Szott added a comment - Please update the control file in the 2.54 deb package since it currently does not reflect the Java 1.8 dependency: Depends: daemon, adduser, procps, psmisc, net-tools, default-jre-headless (>= 2:1.7) | java7-runtime-headless

          Oleg Nenashev added a comment -

          Both Debian packaging and SSH Slaves have been updated. The new Debian package will be released tomorrow

          Oleg Nenashev added a comment - Both Debian packaging and SSH Slaves have been updated. The new Debian package will be released tomorrow

          This is a problem with RHEL/CentOS as well using the 'official' RPM repo:

          yum info jenkins
          Loaded plugins: fastestmirror
          Loading mirror speeds from cached hostfile
          * base: bay.uchicago.edu
          * epel: mirror.us.leaseweb.net
          * extras: mirrors.rit.edu
          * updates: mirror.es.its.nyu.edu
          Installed Packages
          Name : jenkins
          Arch : noarch
          Version : 2.56
          Release : 1.1
          Size : 67 M
          Repo : installed
          From repo : jenkins
          
           yum deplist jenkins
          Loaded plugins: fastestmirror
          Loading mirror speeds from cached hostfile
          * base: repos-va.psychz.net
          * epel: kdeforge2.unl.edu
          * extras: mirror.tzulo.com
          * updates: repos-tx.psychz.net
          package: jenkins.noarch 2.56-1.1
          dependency: /bin/sh
          provider: bash.x86_64 4.2.46-21.el7_3
          dependency: /usr/sbin/groupadd
          provider: shadow-utils.x86_64 2:4.1.5.1-24.el7
          dependency: /usr/sbin/useradd
          provider: shadow-utils.x86_64 2:4.1.5.1-24.el7
          dependency: procps
          provider: procps-ng.x86_64 3.3.10-10.el7
          provider: procps-ng.i686 3.3.10-10.el7
          
          

          Not sure if java was intentionally not present in the dependency list for the RPM (whereas it is apparently listed for the deb packages), but its not there for the rpm ones.  Just in case someone stumbles upon this from a google search.

          Robert Stevens added a comment - This is a problem with RHEL/CentOS as well using the 'official' RPM repo: yum info jenkins Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * base: bay.uchicago.edu * epel: mirror.us.leaseweb.net * extras: mirrors.rit.edu * updates: mirror.es.its.nyu.edu Installed Packages Name : jenkins Arch : noarch Version : 2.56 Release : 1.1 Size : 67 M Repo : installed From repo : jenkins  yum deplist jenkins Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * base: repos-va.psychz.net * epel: kdeforge2.unl.edu * extras: mirror.tzulo.com * updates: repos-tx.psychz.net package : jenkins.noarch 2.56-1.1 dependency: /bin/sh provider: bash.x86_64 4.2.46-21.el7_3 dependency: /usr/sbin/groupadd provider: shadow-utils.x86_64 2:4.1.5.1-24.el7 dependency: /usr/sbin/useradd provider: shadow-utils.x86_64 2:4.1.5.1-24.el7 dependency: procps provider: procps-ng.x86_64 3.3.10-10.el7 provider: procps-ng.i686 3.3.10-10.el7 Not sure if java was intentionally not present in the dependency list for the RPM (whereas it is apparently listed for the deb packages), but its not there for the rpm ones.  Just in case someone stumbles upon this from a google search.

          Oleg Nenashev added a comment -

          rstevens76 Probably as designed: https://github.com/jenkinsci/packaging/pull/96 , CC svanoort. Anyway, it should be created as a separate issue

          Oleg Nenashev added a comment - rstevens76 Probably as designed: https://github.com/jenkinsci/packaging/pull/96 , CC svanoort . Anyway, it should be created as a separate issue

          Sam Van Oort added a comment -

          rstevens76 Java is not on the dependency list for the RPM builds, because the Oracle JDK/JRE does not register as providing the "java" dependency.  This means adding the dependency would forcibly install the OpenJDK version, which can cause consequences for users.

          Sam Van Oort added a comment - rstevens76 Java is not on the dependency list for the RPM builds, because the Oracle JDK/JRE does not register as providing the "java" dependency.  This means adding the dependency would forcibly install the OpenJDK version, which can cause consequences for users.

            Unassigned Unassigned
            ciaran_mccarthy Ciaran McCarthy
            Votes:
            1 Vote for this issue
            Watchers:
            11 Start watching this issue

              Created:
              Updated:
              Resolved: