-
Bug
-
Resolution: Fixed
-
Major
-
None
-
Debian Lenny running Linux 2.6.26-2-amd64
Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_22-b03, mixed mode)
Tomcat 5.5
-
Powered by SuggestiMate
Greetings,
I have upgraded my Jenkins server at home using the latest 1.399 WAR with the intention to fix #JENKINS-8647 (growing log files due to an issue in JmDNS) but it seems that the compatibility with Java 5 is broken by jmdns-3.4.0.jar
I get the following stack trace in my catalina.log at server initialization:
---------- 28 févr. 2011 22:59:49 hudson.WebAppMain$2 run GRAVE: Failed to initialize Hudson 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.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:1853) at org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:875) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1330) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1209) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320) at hudson.DNSMultiCast.<init>(DNSMultiCast.java:26) at hudson.model.Hudson.<init>(Hudson.java:691) at hudson.model.Hudson.<init>(Hudson.java:605) at hudson.WebAppMain$2.run(WebAppMain.java:221) ----------
I will try to build JmDNS 3.4.0 with a Java 5 JDK and see if it fixes the issue. I believe this should be patched in the next release, I might not be the last person stuck with Java 5
Thanks & regards,
--JB.L
- duplicates
-
JENKINS-8909 UnsupportedClassVersionError: Bad version number in .class file
-
- Closed
-
- is duplicated by
-
JENKINS-9014 jmdns-3.4.0.jar compiled with java 1.6 classes => Works not with WebSphere 6.1 (java5)
-
- Resolved
-
- is related to
-
JENKINS-6653 java.lang.UnsupportedClassVersionError: Bad version number in .class file (unable to load class javax.jmdns.JmDNS
-
- Closed
-
-
JENKINS-8647 Hudson 1.395 logs many messages about RecordReaper IllegalArgumentException
-
- Closed
-
[JENKINS-8914] Jenkins 1.399: java.lang.UnsupportedClassVersionError: Bad version number in .class file using JmDNS 3.4.0
An idea from Cedric Beust: http://beust.com/weblog/2011/02/21/verifying-the-version-of-your-java-classes/.
If Jenkins's supported JDK is JDK5, then it might be a good idea to check that.
Cheers
Got this error after upgrading Jenkins to 1.400 from 1.396. A suggested workaround was to use an update JDK (JDK5 installed by default). Unfortunately, I use a PPC Mac OS 10.5 so an upgrade to JDK6 is not possible because it only works for Intel machines for now. Same problem with installing OpenJDK6.
I upgraded to 1.400 after installing some plugins and finding out that some of them require the newest version. I run jenkins using "java -jar jenkins.war" in terminal and got this error:
java.lang.UnsupportedClassVersionError: Bad version number in .class file
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:676)
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 winstone.classLoader.WebappClassLoader.loadClass(WebappClassLoader.java:68)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:375)
at hudson.DNSMultiCast.(DNSMultiCast.java:26)
at hudson.model.Hudson.(Hudson.java:691)
at hudson.model.Hudson.(Hudson.java:605)
at hudson.WebAppMain$2.run(WebAppMain.java:221)
P.S. Sorry if I'm not using the terms right. This is my first foray into CI and I use PHP at work. I don't know much about Java.
Code changed in jenkins
User: Kohsuke Kawaguchi
Path:
changelog.html
core/pom.xml
http://jenkins-ci.org/commit/core/fbac722627164bf9332a1795c4ebfa7dc380c3f8
Log:
[FIXED JENKINS-8914] fixed the JDK1.6 dependency that has crept in 1.400
Integrated in jenkins_main_trunk #594
[FIXED JENKINS-8914] fixed the JDK1.6 dependency that has crept in 1.400
Kohsuke Kawaguchi : fbac722627164bf9332a1795c4ebfa7dc380c3f8
Files :
- core/pom.xml
- changelog.html
Tried today with the latest version (1.403) and still the same issue here. Looks like the vanilla jmdns-3.4.0.jar is still shipped with the WAR (instead of 3.4.0-jenkins-1 as specified in the POM). Thanks.
Well, 1.403 just doesn't include this commit/modification on purpose.
The release process is described here: http://wiki.jenkins-ci.org/display/JENKINS/Release+Process
There's a RC war in there that you might want to check. Jenkins has somehow a ~10/15 days of QA before going out in an official release.
Following the process logic above: as Kohsuke committed on last tuesday, this commit is going into the RC branch just now or the just past WE.
So, I guess 1.404 will include the fix of this bug, not 1.403.
Cheers
OK, thank you for the pointer to the release process. I guess I am being a bit too impatient sorry for the disturbance.
PSST: The svn plugin also seems to require jdk 1.6 - don't know if that was intentional or not
jmDNS 3.4.0 is still shipped in the 1.404 war file - so the Bug is still unresolved in 1.404
And 1.404 doesn't work for me on java 1.5
As Kohsuke Kawaguchi said, it is fixed for 1.405.
Just wait for the 1.405 to be released or download the last rc branch.
So back to marked as fixed
I don't know how this changelog is generated. Maybe it was targeted for 1.404 but because of problems/bugs, it has been delayed for 1.405 to do additional testing.
I'm still in 1.394 because of this bug and the bug it was supposed to correct (numerous logs in tomcat...).
Just wait 1.405 and reopen if it is not fixed.
Just tested 1.405 this morning, it bundles jmdns-3.4.0-jenkins-1.jar, however the problem is still there.
I agree with Vincent. 1.405 doesn't fix this problem. (JBOSS 4.2, IBM JVM 1.5, x86-64)
Indeed. I checked the bundled jmdns-3.4.0-jenkins-1.jar and it consist of class files in version 50.0 (JDK 1.6).
So it's still open.
I checked out jmdns source from https://github.com/jenkinsci/jmdns/tree/3.4.0-jenkin-1 and found the source of the problem. I've submitted a pull request to fix this on https://github.com/jenkinsci/jmdns/pull/1
Code changed in jenkins
User: Vincent Latombe
Path:
core/pom.xml
http://jenkins-ci.org/commit/jenkins/2c3583d1fc561ccc80373456184ca45baeba39b7
Log:
[FIXED JENKINS-8914] Use new patched version of jmdns
Code changed in jenkins
User: Vincent Latombe
Path:
changelog.html
http://jenkins-ci.org/commit/jenkins/d2809f867e985a07a0231a2fd912721c29a4eb3a
Log:
[FIXED JENKINS-8914] Use new patched version of jmdns - Update changelog
Integrated in jenkins_main_trunk #666
[FIXED JENKINS-8914] Use new patched version of jmdns
[FIXED JENKINS-8914] Use new patched version of jmdns - Update changelog
Vincent Latombe : 2c3583d1fc561ccc80373456184ca45baeba39b7
Files :
- core/pom.xml
Vincent Latombe : d2809f867e985a07a0231a2fd912721c29a4eb3a
Files :
- changelog.html
Code changed in jenkins
User: Kohsuke Kawaguchi
Path:
changelog.html
core/pom.xml
http://jenkins-ci.org/commit/jenkins/04484fa69fb8f0d715dee68e44451ad6b40e6105
Log:
[FIXED JENKINS-8914] fixed the JDK1.6 dependency that has crept in 1.400
Code changed in jenkins
User: Vincent Latombe
Path:
core/pom.xml
http://jenkins-ci.org/commit/jenkins/882f81fe0eb9de9979d7e8eca747efebfe5c9d7e
Log:
[FIXED JENKINS-8914] Use new patched version of jmdns
Looked at rc branch. Supposed to be fixed on 1.407. I'll try it today and make you some feedback.
Fixed in 1.407-RC (tested and started correctly). If you want to try it out, go to the RC branch build on Jenkins CI (http://ci.jenkins-ci.org/job/jenkins_rc_branch/) and download jenkins.war. Hope it'll help.
Now works for me in 1.407, was not working in 1.406. Thanks!
OS X Server 10.4 / PowerPC G5
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05-241)
Java HotSpot(TM) Client VM (build 1.5.0_13-121, mixed mode
This seems to work in 1.407. Curiously, I had to downgrade to Tomcat 6 from Tomcat 7 in order for the error to disappear (both are running on the Oracle JDK 6, Update 23). Seems like Tomcat 7 may be leaking its JRE in some way...?
Upgraded to 1.408 today, happily greeted by the new face of Jenkins and everything seems OK. Thanks !
Code changed in jenkins
User: Kohsuke Kawaguchi
Path:
changelog.html
core/pom.xml
http://jenkins-ci.org/commit/jenkins/fbac722627164bf9332a1795c4ebfa7dc380c3f8
Log:
[FIXED JENKINS-8914] fixed the JDK1.6 dependency that has crept in 1.400
Code changed in jenkins
User: Vincent Latombe
Path:
core/pom.xml
http://jenkins-ci.org/commit/jenkins/2c3583d1fc561ccc80373456184ca45baeba39b7
Log:
[FIXED JENKINS-8914] Use new patched version of jmdns
Code changed in jenkins
User: Vincent Latombe
Path:
changelog.html
http://jenkins-ci.org/commit/jenkins/d2809f867e985a07a0231a2fd912721c29a4eb3a
Log:
[FIXED JENKINS-8914] Use new patched version of jmdns - Update changelog
Code changed in jenkins
User: Vincent Latombe
Path:
core/pom.xml
http://jenkins-ci.org/commit/jenkins/2c3583d1fc561ccc80373456184ca45baeba39b7
Log:
[FIXED JENKINS-8914] Use new patched version of jmdns
Code changed in jenkins
User: Vincent Latombe
Path:
changelog.html
http://jenkins-ci.org/commit/jenkins/d2809f867e985a07a0231a2fd912721c29a4eb3a
Log:
[FIXED JENKINS-8914] Use new patched version of jmdns - Update changelog
Jenkins ver. 1.447.2
$ /opt/jdk1.5.0_17/bin/java -Xmx1024m -Xms512m -XX:MaxPermSize=512m -Djava.awt.headless=true -cp /home/jenkins/jenkins/plugins/maven-plugin/WEB-INF/lib/maven3-agent-1.2.jar:/svc/tmv723/home/g_tvpp_b/tools/maven/maven-3.0.3/boot/plexus-classworlds-2.4.jar org.jvnet.hudson.maven3.agent.Maven3Main /home/jenkins/tools/maven/maven-3.0.3 /home/jenkins/tomcat7/webapps/jenkins/WEB-INF/lib/remoting-2.11.jar /home/jenkins/jenkins/plugins/maven-plugin/WEB-INF/lib/maven3-interceptor-1.2.jar 62771
<===[JENKINS REMOTING CAPACITY]===>channel started
channel stopped
ERROR: Failed to parse POMs
java.io.IOException: Remote call on Channel to Maven [/opt/jdk1.5.0_17/bin/java, -Xmx1024m, -Xms512m, -XX:MaxPermSize=512m, -Djava.awt.headless=true, -cp, /home/jenkins/jenkins/plugins/maven-plugin/WEB-INF/lib/maven3-agent-1.2.jar:/home/jenkins/tools/maven/maven-3.0.3/boot/plexus-classworlds-2.4.jar, org.jvnet.hudson.maven3.agent.Maven3Main, /home/jenkins/tools/maven/maven-3.0.3, /home/jenkins/tomcat7/webapps/jenkins/WEB-INF/lib/remoting-2.11.jar, /home/jenkins/jenkins/plugins/maven-plugin/WEB-INF/lib/maven3-interceptor-1.2.jar, 62771] failed
at hudson.remoting.Channel.call(Channel.java:690)
at hudson.maven.ProcessCache$MavenProcess.call(ProcessCache.java:156)
at hudson.maven.MavenModuleSetBuild$RunnerImpl.doRun(MavenModuleSetBuild.java:794)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:467)
at hudson.model.Run.run(Run.java:1404)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:481)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:238)
Caused by: java.lang.ClassFormatError: Failed to load javax.servlet.ServletException
at hudson.remoting.RemoteClassLoader.loadClassFile(RemoteClassLoader.java:154)
at hudson.remoting.RemoteClassLoader.findClass(RemoteClassLoader.java:131)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at hudson.plugins.cobertura.MavenCoberturaPublisher.<clinit>(MavenCoberturaPublisher.java:239)
at sun.misc.Unsafe.ensureClassInitialized(Native Method)
at sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25)
at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122)
at java.lang.reflect.Field.acquireFieldAccessor(Field.java:917)
at java.lang.reflect.Field.getFieldAccessor(Field.java:898)
at java.lang.reflect.Field.getLong(Field.java:527)
at java.io.ObjectStreamClass.getDeclaredSUID(ObjectStreamClass.java:1586)
at java.io.ObjectStreamClass.access$700(ObjectStreamClass.java:52)
at java.io.ObjectStreamClass$2.run(ObjectStreamClass.java:408)
at java.security.AccessController.doPrivileged(Native Method)
at java.io.ObjectStreamClass.<init>(ObjectStreamClass.java:400)
at java.io.ObjectStreamClass.lookup(ObjectStreamClass.java:297)
at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:531)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1552)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1466)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1699)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
at java.util.ArrayList.readObject(ArrayList.java:591)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:946)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1809)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
at java.util.HashMap.readObject(HashMap.java:1067)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:946)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1809)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1908)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1832)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
at hudson.remoting.UserRequest.deserialize(UserRequest.java:182)
at hudson.remoting.UserRequest.perform(UserRequest.java:98)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:287)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
at java.util.concurrent.FutureTask.run(FutureTask.java:123)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
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:620)
at java.lang.ClassLoader.defineClass(ClassLoader.java:465)
at hudson.remoting.RemoteClassLoader.loadClassFile(RemoteClassLoader.java:152)
... 57 more
Originally reported problem was fixed; if there are other incompatibilities affecting current Jenkins releases, they should be filed separately.
https://github.com/jenkinsci/jenkins/pull/781 proposes to prevent this kind of error from recurring.
Code changed in jenkins
User: Baptiste Mathus
Path:
pom.xml
http://jenkins-ci.org/commit/jenkins/b02b14764d0be6c0e41e9dc12e1d97d9300154b2
Log:
Using mojo extra-enforcer-rules enforceBytecodeVersion.
This rule enforces a bytecode version in dependencies.
This would prevent cases like JENKINS-8914 where someone had
introduced a dependency compiled with JDK1.6 at a time where
Jenkins was still on 1.5.
With 1.7 already here and 1.8 coming, this should help no to do that
again.
Seems as need jmdns 3.4.0 to be rebuild as 3.2.1 before (see
JENKINS-6653).