+3  A: 

The problem appears to be in your website, not your code. Googling around, the error seems to be most frequently reported with systems such as OpenCMS (especially for URLs that are on port 8080).

So, what I imagine is happening is that the browser's call to load the applet is actually failing, but is returning data rather than a 404/500 error. The Java VM is attempting to interpret the returned error page as if it was a class file, and quite correctly complaining that it doesn't seem to be a valid class file after all. (This happens quite often with content management systems that redirect to the home page rather than return an actual HTTP error to the user.)

To test, try manually typing the URL to the applet (not the page it is hosted in, the applet itself) in your browser and see what the server returns.

William Billingsley
Ah, yes, it is failing to load the applet. We aren't using a prewritten CMS, though it is using Savant3, and the direct URL to the avatar is returning a 404.
Ben
Uh, excuse me, I mean a direct URL to the applet.
Ben
I was able to add an entry for the applet itself as if it was a separate page, and it resolved this error (though now I have more to debug!). Thank you.
Ben
+3  A: 

The magic number is a four byte value (0xCAFEBABE) at the start of the class file that marks it as a class file rather than any other kind of data.

So what type of file has magic number 1008813135? In hex that becomes that bytes 0x3C, 0x21, 0x44, 0x4F. Interpreted as character data in common Latin encodings is "<!DO. Probably continuing as "<!DOCTYPE". What we have here is an HTML file. This is probably an error page returned by a broken server only with a non-error success code in the HTTP response.

Have a look at what is actually being served. A web browser will probably show the page. It is worth learning to use telnet (or nc) and type in the HTTP response by hand. There are also various utilities for inspecting HTTP traffic.

Tom Hawtin - tackline
Thanks, it appears, as I mentioned in response to the other answer, that it's a 404 page that it's returning, hence the <!DOCTYPE ... > tag.
Ben