tags:

views:

71

answers:

3

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?

+1  A: 

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.

BalusC
+1  A: 

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.

Anon
I edit the code on a windows machine(notepad++) and FTP in ASCII it to an OpenVMS machine, where I then compile it. I have not been cleaning out old class files due to the VMS versioning system.
CheesePls
You need to FTP class files as binary not as text.
BalusC
I'm FTP-ing the .java files not the .class files
CheesePls
Transferring in binary mode didn't work. Zipping then sending as binary then unzipping didn't work either
CheesePls
@CheesePls - for future reference, points like "I'm editing on Windows and compiling on OpenVMS" should go into your original question, as they provide critical information. You shouldn't have an issue if all you're doing is FTP-ing the `.java` files, however I strongly suspect that you're also copying `.class` files. The best way to diagnose this is to create completely new working directories on both machines. Copy just .java files into the Windows working directory, then upload just files from that directory to the new working directory on OpenVMS. Then compiler on OpenVMS.
Anon
A: 

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)

CheesePls