java.lang.ClassFormatError: Dodatkowe bajty na końcu pliku klasy

Question

Otrzymuję nieparzysty błąd podczas próby uruchomienia tego programu. Klasa kompiluje dobrze do wielu plików .class i skompilowałem ją w zeszłym tygodniu (przed edycją) dobrze. Ale teraz widzę, to:

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

Z tego co ja wzrok, Java 6 1.5 build mógł go naprawić, ponieważ umożliwia dodatkowe bajty na końcu plików klasy (myślę), ale Chętniej użyj kompilacji 1.6.

Edytuję w systemie Windows, a następnie FTP -ing plików .java na maszynę OpenVMS, gdzie następnie je kompilować. po kompilacji przenosimy plik .class do katalogu utworzonego przez eksplozję poprzedniego pliku jar, a następnie przeskalujemy go ponownie.

Jakiekolwiek jasne pomysły na temat tego, jak to się stało lub jak to naprawić?

Answer 1

Problem został rozwiązany poprzez usunięcie wszystkich linii Kanały z pliku .java i odpowiednio zmieniając jego nazwę (OpenVMS domyślnie wszystkimi małymi literami, chyba nie powiedział)

Niestety brak z mojej strony, nie testuje się między sobą, ale przynajmniej to działa.

W skrócie:

-line Feeds są złe I Nazwa plików prawidłowo (normy standardów Java nie OS)

Answer 2

To jest rzeczywiście zabronione zgodnie VM Spec 4.9.1:

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

Taka sytuacja może wystąpić, jeśli istnieje niezgodność w kompilatora Java i Java runtime używane. Sprawdź obie wersje i upewnij się, że kompilujesz dla właściwych wersji środowiska wykonawczego. To znaczy. klasa skompilowana może być używana z tą samą lub nowszą wersją środowiska wykonawczego, ale nie zawsze jest toze starszymi wersjami środowiska wykonawczego. Sprawdź wersje przy użyciu java -version i javac -version.

Inną częstą przyczyną jest uszkodzenie pliku podczas przesyłania plików (FTP) między różnymi komputerami. Transfer należy wykonać w trybie binarnym, a nie w trybie tekstowym.

Inną możliwą przyczyną jest błąd sprzętowy, np. uszkodzony dysk twardy/plik/pamięć. Spróbuj dokonać rekompilacji lub innej maszyny.

Answer 3

Wyjaśnienie: dzieje się tak po wyczyszczeniu wszystkich starych plików .class i ponownym kompilowaniu na tym samym komputerze?

A może kompilujesz na jednym komputerze, a następnie kopiujesz pliki do innego? W takim przypadku prawdopodobnie oprogramowanie do przesyłania plików powoduje uszkodzenie plików (Windows < -> Linux jest częstym winowajcą, najczęściej poprzez dodanie/usunięcie bajtu 0x0D, ale czasami przez dodanie znacznika 0xOA DOS EOF).

Podejrzewam, że jeśli sprawdzisz proces, odkryjesz, że gdzieś modyfikujesz pliki poza Javą. Nie ma powodu - nawet zmiany wersji - dla pliku utworzonego przez prawidłowy kompilator Java, aby mieć dodatkowe bajty na końcu.

Answer 4

miałem podobny problem. Po prostu próbowałem napisać jedną klasę na moim biurowym komputerze i przenieść na nasz serwer klienta, aby przetestować coś na <, ponieważ na tej maszynie nie było JDK. Użyłem tej samej wersji java na obu komputerach, ale po transferze otrzymałem ten wyjątek. Próbowałem użyć archiwizatora przed przeniesieniem i pomógł.

Answer 5

Napotkano ten wyjątek tylko podczas programowania. Wydaje mi się, że ECJ Eclipse'a (Eclipse Luna) indukuje to zachowanie. Dla mnie czysty build rozwiązał problem.