Incompatible magic value 1008813135 error with applet

Discussion in 'Java' started by segalsegal, Oct 8, 2010.

  1. segalsegal

    segalsegal Guest

    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, Oct 8, 2010
    #1
    1. Advertising

  2. segalsegal

    segalsegal Guest

    On Oct 8, 3:55 pm, segalsegal <> 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.
    segalsegal, Oct 8, 2010
    #2
    1. Advertising

  3. segalsegal

    GArlington Guest

    On 8 Oct, 20:55, segalsegal <> 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(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
    GArlington, Oct 9, 2010
    #3
  4. segalsegal

    segalsegal Guest

    On Oct 9, 7:29 am, GArlington <> wrote:

    > 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.
    segalsegal, Oct 9, 2010
    #4
  5. segalsegal

    Eric Sosman Guest

    On 10/9/2010 9:13 AM, segalsegal wrote:
    > On Oct 9, 7:29 am, GArlington<> wrote:
    >
    >> 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.

    --
    Eric Sosman
    lid
    Eric Sosman, Oct 9, 2010
    #5
  6. segalsegal

    Lew Guest

    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
    Lew, Oct 9, 2010
    #6
  7. segalsegal

    Carlos Guest

    [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.

    --
    Carlos, Oct 9, 2010
    #7
  8. segalsegal

    Roedy Green Guest

    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/runerrormessages.html#BADMAGICNUMBER

    see http://mindprod.com/jgloss/runerrormessages.html#CLASSFORMATERROR
    --
    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.
    Roedy Green, Oct 9, 2010
    #8
  9. segalsegal

    segalsegal Guest

    On Oct 9, 2:18 pm, Roedy Green <>
    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.
    segalsegal, Oct 10, 2010
    #9
  10. 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
    Joshua Cranmer, Oct 10, 2010
    #10
  11. segalsegal

    Roedy Green Guest

    On Sun, 10 Oct 2010 12:10:33 -0700 (PDT), segalsegal
    <> wrote, quoted or indirectly quoted someone
    who said :

    >On Oct 9, 2:18 pm, Roedy Green <>
    >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.


    What version of Java do you have on these various servers? See
    http://mindprod.com/applet/wassup.html
    --
    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.
    Roedy Green, Oct 11, 2010
    #11
  12. segalsegal

    Carlos Guest

    [segalsegal <>, 2010-10-10 12:10]
    > 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.
    --
    Carlos, Oct 11, 2010
    #12
  13. segalsegal

    segalsegal Guest

    On Oct 11, 12:16 am, Roedy Green <>
    wrote:

    > 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, Oct 12, 2010
    #13
  14. segalsegal

    segalsegal Guest

    On Oct 11, 1:34 pm, Carlos <> wrote:

    > 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.
    segalsegal, Oct 12, 2010
    #14
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. MNQ
    Replies:
    5
    Views:
    2,412
  2. Dennis Schulz

    error: incompatible types in asignment

    Dennis Schulz, May 26, 2004, in forum: C Programming
    Replies:
    2
    Views:
    470
    Emmanuel Delahaye
    May 26, 2004
  3. Jaroslaw Zabiello

    ZPT and "incompatible version None" error :(

    Jaroslaw Zabiello, Sep 12, 2005, in forum: Python
    Replies:
    3
    Views:
    368
    bruno modulix
    Sep 13, 2005
  4. Replies:
    1
    Views:
    313
    Ryan Davis
    May 6, 2005
  5. Giles Bowkett
    Replies:
    9
    Views:
    400
    Giles Bowkett
    Dec 17, 2007
Loading...

Share This Page