You are viewing a plain text version of this content. The canonical link for it is here.
Posted to builds@apache.org by Thomas Fox <Th...@seitenbau.net> on 2012/02/16 04:40:08 UTC
java 1.5 build and "Bad version number in .class file" error
The Torque project has jenkins builds running on the latest 1.5 JDK and the
last builds have failed with the following error (full stack trace below)
...
Caused by: java.lang.ClassFormatError: Failed to load
javax.servlet.ServletException
...
Caused by: java.lang.UnsupportedClassVersionError: Bad version number
in .class file
...
The error occurs before the project is compiled, so this does not seem to
be a problem in the project set-up but rather in jenkins itself.
After setting the jdk to 1.6-latest, the build runs ok but this is not a
permanent solution as we want to ensure buildability on java 1.5.
We use maven-2.2.1 and are running on ubuntu nodes.
Any help is appreciated. I have re-configured to use jdk 1.5, feel free to
start builds to analyze the behaviour.
Thanks,
Thomas
failed build example (jdk 1.5)
https://builds.apache.org/view/S-Z/view/Torque/job/Torque4-trunk/61/
working build example(jdk 1.6)
https://builds.apache.org/view/S-Z/view/Torque/job/Torque4-trunk/62/
Full console output, failed build:
Started by user tfischer
Building remotely on ubuntu1 in
workspace /home/jenkins/jenkins-slave/workspace/Torque4-trunk
Cleaning
up /home/jenkins/jenkins-slave/workspace/Torque4-trunk/torque4-trunk
Updating http://svn.apache.org/repos/asf/db/torque/torque4/trunk
At revision 1244828
no change for http://svn.apache.org/repos/asf/db/torque/torque4/trunk since
the previous build
Parsing POMs
[torque-maven-parent] $ /home/hudson/tools/java/latest1.5/bin/java
-cp /home/jenkins/jenkins-slave/maven-agent.jar:/home/jenkins/jenkins-slave/classworlds.jar
hudson.maven.agent.Main /home/hudson/tools/maven/apache-maven-2.2.1 /home/jenkins/jenkins-slave/slave.jar /home/jenkins/jenkins-slave/maven-interceptor.jar
40457 /home/jenkins/jenkins-slave/maven2.1-interceptor.jar
<===[JENKINS REMOTING CAPACITY]===>channel started
���channel stopped
ERROR: Failed to parse POMs
java.io.IOException: Remote call on Channel to Maven
[/home/hudson/tools/java/latest1.5/bin/java,
-cp, /home/jenkins/jenkins-slave/maven-agent.jar:/home/jenkins/jenkins-slave/classworlds.jar,
hudson.maven.agent.Main, /home/hudson/tools/maven/apache-maven-2.2.1, /home/jenkins/jenkins-slave/slave.jar, /home/jenkins/jenkins-slave/maven-interceptor.jar,
40457, /home/jenkins/jenkins-slave/maven2.1-interceptor.jar] 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:795)
at hudson.model.AbstractBuild$AbstractRunner.run
(AbstractBuild.java:470)
at hudson.model.Run.run(Run.java:1409)
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:307)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at java.lang.ClassLoader.loadClassInternal
(ClassLoader.java:320)
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:918)
at java.lang.reflect.Field.getFieldAccessor(Field.java:899)
at java.lang.reflect.Field.getLong(Field.java:528)
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.GeneratedMethodAccessor2.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:592)
at java.io.ObjectStreamClass.invokeReadObject
(ObjectStreamClass.java:946)
at java.io.ObjectInputStream.readSerialData
(ObjectInputStream.java:1812)
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:592)
at java.io.ObjectStreamClass.invokeReadObject
(ObjectStreamClass.java:946)
at java.io.ObjectInputStream.readSerialData
(ObjectInputStream.java:1812)
at java.io.ObjectInputStream.readOrdinaryObject
(ObjectInputStream.java:1719)
at java.io.ObjectInputStream.readObject0
(ObjectInputStream.java:1305)
at java.io.ObjectInputStream.defaultReadFields
(ObjectInputStream.java:1910)
at java.io.ObjectInputStream.readSerialData
(ObjectInputStream.java:1834)
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 hudson.remoting.InterceptingExecutorService$1.call
(InterceptingExecutorService.java:72)
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:651)
at java.util.concurrent.ThreadPoolExecutor$Worker.run
(ThreadPoolExecutor.java:676)
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:152)
... 56 more
Skipping Cobertura coverage report as build was not UNSTABLE or better ...
Finished: FAILURE
Re: java 1.5 build and "Bad version number in .class file" error
Posted by Olivier Lamy <ol...@apache.org>.
2012/2/16 Konstantin Kolinko <kn...@gmail.com>:
> 2012/2/16 Olivier Lamy <ol...@apache.org>:
>> The issue is running Jenkins on Tomcat7 with maven build using jdk1.5 .
>> Jenkins jobs (with jdk1.5) try to load some classes (in our cases
>> javax.servlet.* ) from master node.
>> And in this case they come from tomcat classLoader and are "marked"
>> 1.6 result -> "Caused by: java.lang.UnsupportedClassVersionError: Bad
>> version number in .class file"
>>
>> I don't have any quick fix now or workaround. Expect revert Jenkins
>> master running on tc 6.x
>
>
> I cannot say whether it is relevant, but just for general info:
>
> When web application that runs on Tomcat tries to load javax.servlet.*
> classes, they are always loaded from Tomcat class loader. You are not
> allowed to load them from anywhere else. You are not allowed to put
> them into your WEB-INF/lib folder.
>
> This requirement is from Servlet specification, ch. 10.7.2 in Servlet 3.0
> (it was chapter SRV..9.7.2 in Servlet 2.5),
> so it should not be something unique to Tomcat.
> It is implemented in WebappClassLoader#validate() [1].
>
> [1] http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/catalina/loader/WebappClassLoader.java?view=markup#l3295
>
> I have no clue why Jenkins tries to serialize those classes.
Jenkins use a remoteclassloader mechanism to execute jobs on slave
node (non available classes are loaded from the master node).
So in our case, a 1.5 vm is started on the slave node, this vm try to
load some classes from master (and some classes are 1.6).
BTW it's a Jenkins architecture issue (not a Tomcat issue :-) ).
>
> Tomcat 7 runs on Java 6+, so there is no wonder that its classes are
> compiled on that version of Java.
>
>> 2012/2/16 Niklas Gustavsson <ni...@protocol7.com>:
>>> On Thu, Feb 16, 2012 at 9:50 AM, Olivier Lamy <ol...@apache.org> wrote:
>>>> It's on my TODO list to debug/fix this jenkins issue.
>>>> I will try to work on that today.
>>>
>>> I tried to downgrade the Cobertura publisher mentioned in the
>>> stacktrace to no improvement.
>>>
>>
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: java 1.5 build and "Bad version number in .class file" error
Posted by Konstantin Kolinko <kn...@gmail.com>.
2012/2/16 Olivier Lamy <ol...@apache.org>:
> The issue is running Jenkins on Tomcat7 with maven build using jdk1.5 .
> Jenkins jobs (with jdk1.5) try to load some classes (in our cases
> javax.servlet.* ) from master node.
> And in this case they come from tomcat classLoader and are "marked"
> 1.6 result -> "Caused by: java.lang.UnsupportedClassVersionError: Bad
> version number in .class file"
>
> I don't have any quick fix now or workaround. Expect revert Jenkins
> master running on tc 6.x
I cannot say whether it is relevant, but just for general info:
When web application that runs on Tomcat tries to load javax.servlet.*
classes, they are always loaded from Tomcat class loader. You are not
allowed to load them from anywhere else. You are not allowed to put
them into your WEB-INF/lib folder.
This requirement is from Servlet specification, ch. 10.7.2 in Servlet 3.0
(it was chapter SRV..9.7.2 in Servlet 2.5),
so it should not be something unique to Tomcat.
It is implemented in WebappClassLoader#validate() [1].
[1] http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/catalina/loader/WebappClassLoader.java?view=markup#l3295
I have no clue why Jenkins tries to serialize those classes.
Tomcat 7 runs on Java 6+, so there is no wonder that its classes are
compiled on that version of Java.
> 2012/2/16 Niklas Gustavsson <ni...@protocol7.com>:
>> On Thu, Feb 16, 2012 at 9:50 AM, Olivier Lamy <ol...@apache.org> wrote:
>>> It's on my TODO list to debug/fix this jenkins issue.
>>> I will try to work on that today.
>>
>> I tried to downgrade the Cobertura publisher mentioned in the
>> stacktrace to no improvement.
>>
>
Re: java 1.5 build and "Bad version number in .class file" error
Posted by Thomas Fox <Th...@seitenbau.net>.
> Just reverted to 6.0.35
> Looks to be better:
https://builds.apache.org/job/Torque4-trunk/68/console
Thanks a lot! The build looks good now.
> @Torque folks I have changed your cron scm pooling which was * * * * *
> (every minutes) to @hourly
> Please avoid using such value !
Ok, thanks. I looked at the jenkins wiki site
http://wiki.apache.org/general/Jenkins?action=show&redirect=Hudson#Are_there_recommended_or_mandatory_Jenkins_settings_for_ASF_projects.3F
and did not find any restrictions there, so I thought every minute was ok.
Perhaps others assume the same so it would be worth documenting a
recommended setting there.
Thanks,
Thomas
> 2012/2/16 Olivier Lamy <ol...@apache.org>:
> > The issue is running Jenkins on Tomcat7 with maven build using jdk1.5 .
> > Jenkins jobs (with jdk1.5) try to load some classes (in our cases
> > javax.servlet.* ) from master node.
> > And in this case they come from tomcat classLoader and are "marked"
> > 1.6 result -> "Caused by: java.lang.UnsupportedClassVersionError: Bad
> > version number in .class file"
> >
> > I don't have any quick fix now or workaround. Expect revert Jenkins
> > master running on tc 6.x
> >
> > 2012/2/16 Niklas Gustavsson <ni...@protocol7.com>:
> >> On Thu, Feb 16, 2012 at 9:50 AM, Olivier Lamy <ol...@apache.org>
wrote:
> >>> It's on my TODO list to debug/fix this jenkins issue.
> >>> I will try to work on that today.
> >>
> >> I tried to downgrade the Cobertura publisher mentioned in the
> >> stacktrace to no improvement.
> >>
> >> /niklas
> >
> >
> >
> > --
> > Olivier Lamy
> > Talend: http://coders.talend.com
> > http://twitter.com/olamy | http://linkedin.com/in/olamy
>
>
>
> --
> Olivier Lamy
> Talend: http://coders.talend.com
> http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: java 1.5 build and "Bad version number in .class file" error
Posted by Olivier Lamy <ol...@apache.org>.
Just reverted to 6.0.35
Looks to be better: https://builds.apache.org/job/Torque4-trunk/68/console
@Torque folks I have changed your cron scm pooling which was * * * * *
(every minutes) to @hourly
Please avoid using such value !
2012/2/16 Olivier Lamy <ol...@apache.org>:
> The issue is running Jenkins on Tomcat7 with maven build using jdk1.5 .
> Jenkins jobs (with jdk1.5) try to load some classes (in our cases
> javax.servlet.* ) from master node.
> And in this case they come from tomcat classLoader and are "marked"
> 1.6 result -> "Caused by: java.lang.UnsupportedClassVersionError: Bad
> version number in .class file"
>
> I don't have any quick fix now or workaround. Expect revert Jenkins
> master running on tc 6.x
>
> 2012/2/16 Niklas Gustavsson <ni...@protocol7.com>:
>> On Thu, Feb 16, 2012 at 9:50 AM, Olivier Lamy <ol...@apache.org> wrote:
>>> It's on my TODO list to debug/fix this jenkins issue.
>>> I will try to work on that today.
>>
>> I tried to downgrade the Cobertura publisher mentioned in the
>> stacktrace to no improvement.
>>
>> /niklas
>
>
>
> --
> Olivier Lamy
> Talend: http://coders.talend.com
> http://twitter.com/olamy | http://linkedin.com/in/olamy
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: java 1.5 build and "Bad version number in .class file" error
Posted by Olivier Lamy <ol...@apache.org>.
The issue is running Jenkins on Tomcat7 with maven build using jdk1.5 .
Jenkins jobs (with jdk1.5) try to load some classes (in our cases
javax.servlet.* ) from master node.
And in this case they come from tomcat classLoader and are "marked"
1.6 result -> "Caused by: java.lang.UnsupportedClassVersionError: Bad
version number in .class file"
I don't have any quick fix now or workaround. Expect revert Jenkins
master running on tc 6.x
2012/2/16 Niklas Gustavsson <ni...@protocol7.com>:
> On Thu, Feb 16, 2012 at 9:50 AM, Olivier Lamy <ol...@apache.org> wrote:
>> It's on my TODO list to debug/fix this jenkins issue.
>> I will try to work on that today.
>
> I tried to downgrade the Cobertura publisher mentioned in the
> stacktrace to no improvement.
>
> /niklas
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: java 1.5 build and "Bad version number in .class file" error
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Thu, Feb 16, 2012 at 9:50 AM, Olivier Lamy <ol...@apache.org> wrote:
> It's on my TODO list to debug/fix this jenkins issue.
> I will try to work on that today.
I tried to downgrade the Cobertura publisher mentioned in the
stacktrace to no improvement.
/niklas
Re: java 1.5 build and "Bad version number in .class file" error
Posted by Olivier Lamy <ol...@apache.org>.
Hello,
It's on my TODO list to debug/fix this jenkins issue.
I will try to work on that today.
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
2012/2/16 Thomas Fox <Th...@seitenbau.net>:
>
> The Torque project has jenkins builds running on the latest 1.5 JDK and the
> last builds have failed with the following error (full stack trace below)
> ...
> Caused by: java.lang.ClassFormatError: Failed to load
> javax.servlet.ServletException
> ...
> Caused by: java.lang.UnsupportedClassVersionError: Bad version number
> in .class file
> ...
> The error occurs before the project is compiled, so this does not seem to
> be a problem in the project set-up but rather in jenkins itself.
>
> After setting the jdk to 1.6-latest, the build runs ok but this is not a
> permanent solution as we want to ensure buildability on java 1.5.
>
> We use maven-2.2.1 and are running on ubuntu nodes.
>
> Any help is appreciated. I have re-configured to use jdk 1.5, feel free to
> start builds to analyze the behaviour.
>
> Thanks,
>
> Thomas
>
> failed build example (jdk 1.5)
> https://builds.apache.org/view/S-Z/view/Torque/job/Torque4-trunk/61/
>
> working build example(jdk 1.6)
> https://builds.apache.org/view/S-Z/view/Torque/job/Torque4-trunk/62/
>
> Full console output, failed build:
> Started by user tfischer
> Building remotely on ubuntu1 in
> workspace /home/jenkins/jenkins-slave/workspace/Torque4-trunk
> Cleaning
> up /home/jenkins/jenkins-slave/workspace/Torque4-trunk/torque4-trunk
> Updating http://svn.apache.org/repos/asf/db/torque/torque4/trunk
> At revision 1244828
> no change for http://svn.apache.org/repos/asf/db/torque/torque4/trunk since
> the previous build
> Parsing POMs
> [torque-maven-parent] $ /home/hudson/tools/java/latest1.5/bin/java
> -cp /home/jenkins/jenkins-slave/maven-agent.jar:/home/jenkins/jenkins-slave/classworlds.jar
>
> hudson.maven.agent.Main /home/hudson/tools/maven/apache-maven-2.2.1 /home/jenkins/jenkins-slave/slave.jar /home/jenkins/jenkins-slave/maven-interceptor.jar
> 40457 /home/jenkins/jenkins-slave/maven2.1-interceptor.jar
> <===[JENKINS REMOTING CAPACITY]===>channel started
> ���channel stopped
> ERROR: Failed to parse POMs
> java.io.IOException: Remote call on Channel to Maven
> [/home/hudson/tools/java/latest1.5/bin/java,
> -cp, /home/jenkins/jenkins-slave/maven-agent.jar:/home/jenkins/jenkins-slave/classworlds.jar,
>
> hudson.maven.agent.Main, /home/hudson/tools/maven/apache-maven-2.2.1, /home/jenkins/jenkins-slave/slave.jar, /home/jenkins/jenkins-slave/maven-interceptor.jar,
> 40457, /home/jenkins/jenkins-slave/maven2.1-interceptor.jar] 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:795)
> at hudson.model.AbstractBuild$AbstractRunner.run
> (AbstractBuild.java:470)
> at hudson.model.Run.run(Run.java:1409)
> 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:307)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
> at java.lang.ClassLoader.loadClassInternal
> (ClassLoader.java:320)
> 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:918)
> at java.lang.reflect.Field.getFieldAccessor(Field.java:899)
> at java.lang.reflect.Field.getLong(Field.java:528)
> 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.GeneratedMethodAccessor2.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:592)
> at java.io.ObjectStreamClass.invokeReadObject
> (ObjectStreamClass.java:946)
> at java.io.ObjectInputStream.readSerialData
> (ObjectInputStream.java:1812)
> 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:592)
> at java.io.ObjectStreamClass.invokeReadObject
> (ObjectStreamClass.java:946)
> at java.io.ObjectInputStream.readSerialData
> (ObjectInputStream.java:1812)
> at java.io.ObjectInputStream.readOrdinaryObject
> (ObjectInputStream.java:1719)
> at java.io.ObjectInputStream.readObject0
> (ObjectInputStream.java:1305)
> at java.io.ObjectInputStream.defaultReadFields
> (ObjectInputStream.java:1910)
> at java.io.ObjectInputStream.readSerialData
> (ObjectInputStream.java:1834)
> 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 hudson.remoting.InterceptingExecutorService$1.call
> (InterceptingExecutorService.java:72)
> 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:651)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run
> (ThreadPoolExecutor.java:676)
> 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:152)
> ... 56 more
> Skipping Cobertura coverage report as build was not UNSTABLE or better ...
> Finished: FAILURE