Incompatible magic value 1008813135 error with applet

[segalsegal]

I'm in the process of switching to Eclipse and running into a strange
problem with reading classes in the new JAR file for my applet. The
error message is below, but the important part seems to be
"java.lang.ClassFormatError: Incompatible magic value 1008813135".

Searching the Web using this message reveals that the 1008813135
corresponds to the sequence of characters "<!DO" and indicates that
the server is trying to load the JAR file as the beginning of an
HTML / XML page, presumably with test beginning with "<!DOCTYPE".
Various people suggested clearing the Java cache, but that doesn't fix
the problem.

I'm having trouble debugging this problem because it occurs on some
computers, not others. It occurs on none of the 4 computers I tested
myself, but of the two others at remote locations whom I asked to
check the loading, one got the problem on one of two computers and the
other got the problem on one of one computers tested, but apparently
only on the second time loading the applet.

When I swap in the version of the JAR file made using an older
compiler from which I'm trying to upgrade, it works fine. So the
problem doesn't seem to be the server or the location on the server,
it seems to be something about the new JAR file.

Does anyone have suggestions how to fix this problem?

The full error message is:

java.lang.ClassFormatError: Incompatible magic value 1008813135 in
class file mypackage/m
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(Unknown Source)
at java.lang.ClassLoader.defineClass(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at sun.plugin2.applet.Applet2ClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadCode(Unknown Source)
at sun.plugin2.applet.Plugin2Manager.createApplet(Unknown Source)
at sun.plugin2.applet.Plugin2Manager
$AppletExecutionRunnable.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Exception: java.lang.ClassFormatError: Incompatible magic value
1008813135 in class file mypackage/m

 

[segalsegal]

... the other got the problem on one of one computers tested, but
apparently only on the second time loading the applet.

There was one error in my original post. There was not an instance of
a person getting the applet to load the first time but not again.
When I got more information I found that it hadn't worked the first
time either, and I got the wrong impression based on the person
following troubleshooting instructions resourcefully. So this seems
like more evidence against a caching problem.

 

[GArlington]

I'm in the process of switching to Eclipse and running into a strange
problem with reading classes in the new JAR file for my applet.  The
error message is below, but the important part seems to be
"java.lang.ClassFormatError: Incompatible magic value 1008813135".

Searching the Web using this message reveals that the 1008813135
corresponds to the sequence of characters "<!DO" and indicates that
the server is trying to load the JAR file as the beginning of an
HTML / XML page, presumably with test beginning with "<!DOCTYPE".
Various people suggested clearing the Java cache, but that doesn't fix
the problem.

I'm having trouble debugging this problem because it occurs on some
computers, not others.  It occurs on none of the 4 computers I tested
myself, but of the two others at remote locations whom I asked to
check the loading, one got the problem on one of two computers and the
other got the problem on one of one computers tested, but apparently
only on the second time loading the applet.

When I swap in the version of the JAR file made using an older
compiler from which I'm trying to upgrade, it works fine.  So the
problem doesn't seem to be the server or the location on the server,
it seems to be something about the new JAR file.

Does anyone have suggestions how to fix this problem?

The full error message is:

java.lang.ClassFormatError: Incompatible magic value 1008813135 in
class file mypackage/m
 at java.lang.ClassLoader.defineClass1(Native Method)
 at java.lang.ClassLoader.defineClassCond(Unknown Source)
 at java.lang.ClassLoader.defineClass(Unknown Source)
 at java.security.SecureClassLoader.defineClass(Unknown Source)
 at sun.plugin2.applet.Applet2ClassLoader.findClass(Unknown Source)
 at java.lang.ClassLoader.loadClass(Unknown Source)
 at java.lang.ClassLoader.loadClass(Unknown Source)
 at sun.plugin2.applet.Plugin2ClassLoader.loadCode(Unknown Source)
 at sun.plugin2.applet.Plugin2Manager.createApplet(Unknown Source)
 at sun.plugin2.applet.Plugin2Manager
$AppletExecutionRunnable.run(Unknown Source)
 at java.lang.Thread.run(Unknown Source)
Exception: java.lang.ClassFormatError: Incompatible magic value
1008813135 in class file mypackage/m

Look at the first result:
http://www.google.co.uk/search?q=+I...s=org.mozilla:en-US:official&client=firefox-a

 

[segalsegal]

Look at the first result:http://www.google.co.uk/search?q=+Incompatible+magic+value&ie=utf-8&o...

http://forums.sun.com/thread.jspa?threadID=646555 describes a
different message, but maybe for a related reason. The thread refers
to several different possibilities, but the part about inner classes
isn't relevant because my applet has no inner classes and the error is
in the class that extends Applet. There may be an issue with
different Java versions since I am using a Java 1.7 version for
compiling the code.

The hardest part about this is that all 6 of our computers, with a
variety of different Java versions, browsers and operating systems,
have no trouble at all with running the applet. But two of the three
computers tested by people at other locations are getting this
error. If we could reproduce the error in-house it would be much
easier to deal with it. If anyone has any sense of what differences
could account for our inability to see the error locally that would be
very helpful. In all cases we are running the applet from the Web and
the error occurs on first run, so this does not seem like a caching
problem.

 

[Eric Sosman]

Look at the first result:http://www.google.co.uk/search?q=+Incompatible+magic+value&ie=utf-8&o...

http://forums.sun.com/thread.jspa?threadID=646555 describes a
different message, but maybe for a related reason.[...]

I suspect GArlington is on the right track. The mysterious
magic number 1008813135 is 3C21444F in hexadecimal, and those four
pairs of digits are the ASCII codes for "<!DO", which looks more
like the start of "<!DOCTYPE" than like the start of a Java class
file (which begins with hex CAFEBABE). Try to get a look at the
characters beyond the first four; I have a notion you might find
them informative.

 

[Lew]

http://forums.sun.com/thread.jspa?threadID=646555 describes a
different message, but maybe for a related reason.[...]

I suspect GArlington is on the right track. The mysterious
magic number 1008813135 is 3C21444F in hexadecimal, and those four
pairs of digits are the ASCII codes for "<!DO", which looks more
like the start of "<!DOCTYPE" than like the start of a Java class
file (which begins with hex CAFEBABE). Try to get a look at the
characters beyond the first four; I have a notion you might find
them informative.

Coding is easy compared to deployment and configuration.

 

[Carlos]

The hardest part about this is that all 6 of our computers, with a
variety of different Java versions, browsers and operating systems,
have no trouble at all with running the applet. But two of the three
computers tested by people at other locations are getting this
error. If we could reproduce the error in-house it would be much
easier to deal with it. If anyone has any sense of what differences
could account for our inability to see the error locally that would be
very helpful. In all cases we are running the applet from the Web and
the error occurs on first run, so this does not seem like a caching
problem.

The web server that is supposed to deliver class/jar files is probably
sending and HTML page with an error message, or something like that.

--

 

[Roedy Green]

"java.lang.ClassFormatError: Incompatible magic value 1008813135".

see http://mindprod.com/jgloss/runerrormessages.html#BADMAGICNUMBER

see http://mindprod.com/jgloss/runerrormessages.html#CLASSFORMATERROR

 

[segalsegal]

seehttp://mindprod.com/jgloss/runerrormessages.html#BADMAGICNUMBER

seehttp://mindprod.com/jgloss/runerrormessages.html#CLASSFORMATERROR

Roedy: it is always great to have you parachute in with advice, but in
this case I don't think it is any of the total fail problems that you
described because it works on all 7 computers I've tested myself and
one 1 of 3 that others have tested. And the version of the code
compiled with an ancient compiler targeted at Java 1.1 works fine on
all 10 of those computers. So it doesn't seem like something related
to how the files are loaded, and it doesn't seem like a problem in the
server itself, and it doesn't seem like something that is totally
broken since it works on 8 of 10 computers tested. It is something
that fails under some relatively unusual circumstances and I haven't
been able to characterize what is unusual about the environments in
which it fails.

What makes this frustrating is that despite having 7 different
computers onsite, with a wide variety of different OSs, I can't
reproduce the problem locally. So I will need to make various test
versions and get other people to test for me.

My #1 suspect is that this is due to using a very old JAR file
program. My #2 suspect is something related to using an obfuscator,
an old one at that. It seems like I'll have to try various
combinations and get others to test. I'm going to be away most of
this week so won't get to try this for at least a week, but I'll
report back with an answer if I find one and I look forward to being
able to add another fixable problem to Roedy's helpful listings.

But brilliant ideas are always welcome.

 

[Joshua Cranmer]

Searching the Web using this message reveals that the 1008813135
corresponds to the sequence of characters "<!DO" and indicates that
the server is trying to load the JAR file as the beginning of an
HTML / XML page, presumably with test beginning with "<!DOCTYPE".
Various people suggested clearing the Java cache, but that doesn't fix
the problem.

If you could, it would be very helpful to see what the "class file"
really contains.

One suggestion of doing this:

java.lang.ClassFormatError: Incompatible magic value 1008813135 in
class file mypackage/m
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(Unknown Source)
at java.lang.ClassLoader.defineClass(Unknown Source)

Grab the source code to java.lang.ClassLoader, rewrite the
java.lang.ClassLoader class to have defineClass catch said error and
dump the "class" to some file, and hook this modified classloader into
the bootstrap class path.

 

[Roedy Green]

Roedy: it is always great to have you parachute in with advice, but in
this case I don't think it is any of the total fail problems that you
described because it works on all 7 computers I've tested myself and
one 1 of 3 that others have tested. And the version of the code
compiled with an ancient compiler targeted at Java 1.1 works fine on
all 10 of those computers. So it doesn't seem like something related
to how the files are loaded, and it doesn't seem like a problem in the
server itself, and it doesn't seem like something that is totally
broken since it works on 8 of 10 computers tested. It is something
that fails under some relatively unusual circumstances and I haven't
been able to characterize what is unusual about the environments in
which it fails.

What makes this frustrating is that despite having 7 different
computers onsite, with a wide variety of different OSs, I can't
reproduce the problem locally. So I will need to make various test
versions and get other people to test for me.

My #1 suspect is that this is due to using a very old JAR file
program. My #2 suspect is something related to using an obfuscator,
an old one at that. It seems like I'll have to try various
combinations and get others to test. I'm going to be away most of
this week so won't get to try this for at least a week, but I'll
report back with an answer if I find one and I look forward to being
able to add another fixable problem to Roedy's helpful listings.

But brilliant ideas are always welcome.

What version of Java do you have on these various servers? See
http://mindprod.com/applet/wassup.html

 

[Carlos]

What makes this frustrating is that despite having 7 different
computers onsite, with a wide variety of different OSs, I can't
reproduce the problem locally.

If it's not your web server, then it can be their proxy or firewall.
--

 

[segalsegal]

What version of Java do you have on these various servers? Seehttp://mindprod.com/applet/wassup.html

That was one of the first things I asked of the first person with the
error message and he has 1.6.0_20. I've been using 1.6.0_21 with no
problem.

 

[segalsegal]

If it's not your web server, then it can be their proxy or firewall.

They can load the same applet built using older technology, so
although a proxy or firewall may be part of the bad interaction it
seems like there is something about the deployment process that is
different and causing the problem. When I'm back next week from
conferences I'll go through the possibilities and ask someone affected
by the problem to give me feedback. It is just hard to do when one
has to depend on others at remote locations for every feedback step in
debugging a problem.