java.lang.ClassFormatError: Extra bytes at end of

Question

I'm getting an odd error when I try and run this program. The class compiles fine into multiple .class files and I compiled it last week (before editing it) just fine. But now, I see this:

Exception in thread "main" java.lang.ClassFormatError: Extra bytes at the end of class file blah/hooplah/fubar/nonsense/IndexId$Transaction

From what I've looked up, Java 6 build 1.5 could fix it since it allows extra bytes at the end of class files (I think), but I would much rather use build 1.6.

I'm editing on Windows and then FTP-ing the .java files over to an OpenVMS machine where I then compile them. after compiling I move the .class file into a directory created from exploding the previous jar file and then re-jar.

Any clear ideas on how this happened or how to fix it?

Answer 1

To clarify: this happens after you've cleaned out all old .class files and recompiled on the same machine?

Or are you compiling on one machine and then copying the files to another? If that's the case, then it's likely that your file transfer software is corrupting the files (Windows <-> Linux is a common culprit, most often by adding/removing a 0x0D byte, but occasionally by adding a 0x1A DOS EOF marker).

I suspect that if you check your process, you'll find that somewhere you're modifying the files outside of Java. There's no reason -- even version changes -- for a file produced by a valid Java compiler to have extra bytes at the end.

Answer 2

I have encountered that exception during development only. It seems to me that Eclipse's ECJ (Eclipse Luna) induces that behaviour. For me a clean build solved the issue.

Answer 3

This is indeed disallowed as per VM Spec 4.9.1:

The class file must not be truncated or have extra bytes at the end.

This can occur if there's an incompatibility in Java compiler and Java runtime used. Verify both versions and make sure that you compile for the right runtime versions. I.e. the compiled class can be used with same or newer runtime version, but not always with older runtime versions. Check the versions using java -version and javac -version.

Another common cause is that the file get corrupted during file transfer (FTP) between different machines. This transfer should be done in binary mode rather than text mode.

Another possible cause is a hardware error, e.g. corrupt harddisk/file/memory. Try recompiling or another machine.

Answer 4

The problem was solved by removing all Line Feeds from the .java file and properly renaming it(OpenVMS defaults to all lower case unless told not to)

Sadly a failure on my part by not testing between each but at least it works.

In short:

-Line Feeds are bad AND Name files properly (Java standards not OS standards)

Answer 5

I had similar problem. I just tried to write one class on my office PC and transfer to our client server to test something< because there were not JDK on that machine. I used the same version of java on both machines but after a transfer I got that Exception. I tried to use archiver before transferring and it helped.