«

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(Unknow n Source)
at sun.plugin2.applet.Applet2ClassLoader.findClass(Un known Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadCode(Unk nown Source)
at sun.plugin2.applet.Plugin2Manager.createApplet(Unk nown 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

On Oct 8, 3:55*pm, segalsegal <googlegro...@segal.org> wrote:
> ... 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.

On 8 Oct, 20:55, segalsegal <googlegro...@segal.org> wrote:
> 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(Unknow n Source)
> *at sun.plugin2.applet.Applet2ClassLoader.findClass(Un known Source)
> *at java.lang.ClassLoader.loadClass(Unknown Source)
> *at java.lang.ClassLoader.loadClass(Unknown Source)
> *at sun.plugin2.applet.Plugin2ClassLoader.loadCode(Unk nown Source)
> *at sun.plugin2.applet.Plugin2Manager.createApplet(Unk nown 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=+In...ient=firefox-a

On Oct 9, 7:29*am, GArlington <garling...@tiscali.co.uk> wrote:

> Look at the first result:http://www.google.co.uk/search?q=+In...lue&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.

On 10/9/2010 9:13 AM, segalsegal wrote:
> On Oct 9, 7:29 am, GArlington<garling...@tiscali.co.uk> wrote:
>
>> Look at the first result:http://www.google.co.uk/search?q=+In...lue&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.

--
Eric Sosman
lid

GArlington wrote:
>>> Look at the first result:
>>><http://www.google.co.uk/search?q=+Incompatible+magic+value>

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

Eric Sosman wrote:
> 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.

--
Lew

[segalsegal <>, 2010-10-09 06:13]
> 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.

--

On Fri, 8 Oct 2010 12:55:37 -0700 (PDT), segalsegal
<> wrote, quoted or indirectly quoted someone
who said :

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

see http://mindprod.com/jgloss/runerrorm...BADMAGICNUMBER

see http://mindprod.com/jgloss/runerrorm...ASSFORMATERROR
--
Roedy Green Canadian Mind Products
http://mindprod.com

You encapsulate not just to save typing, but more importantly, to make it easy and safe to change the code later, since you then need change the logic in only one place. Without it, you might fail to change the logic in all the places it occurs.

On Oct 9, 2:18*pm, Roedy Green <see_webs...@mindprod.com.invalid>
wrote:
> 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.

On 10/08/2010 03:55 PM, segalsegal wrote:
> 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.

--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth