java.lang.ClassFormatError: дополнительные байты в конце файла класса

Question

Я получаю странную ошибку при попытке запустить эту программу. Класс компилируется в несколько файлов .class, и я скомпилировал его на прошлой неделе (перед его редактированием) просто отлично. Но теперь, я вижу это:

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

Из того, что я посмотрел, Java 6 построить 1,5 может исправить это, так как это позволяет дополнительные байты в конце файлов класса (я думаю), но я бы предпочел использовать сборку 1.6.

Я редактирую на Windows, а затем FTP-файлы .java на машину OpenVMS, где я их компилирую. после компиляции я перемещаю файл .class в каталог, созданный из взлома предыдущего файла jar, а затем повторно jar.

Любые четкие идеи о том, как это произошло или как это исправить?

Answer 1

Проблема была решена путем удаления всех Линию каналы из файла .java и правильно переименовать его (OpenVMS по умолчанию в нижнем регистре, если не оговорено обратное)

К сожалению, неудача с моей стороны, не испытывая между собой, но по крайней мере, он работает.

Короче:

-Line Ленты плохие И Имя правильно файлы (стандарты стандартов Java не OS)

Answer 2

Это действительно запрещено согласно VM Spec 4.9.1:

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

Это может произойти, если есть несовместимость в Java компилятора и времени выполнения Java используется. Проверьте обе версии и убедитесь, что вы скомпилируете нужные версии. То есть скомпилированный класс может использоваться с той же или более новой версией исполнения, но не всегда со старыми версиями. Проверьте версии с помощью java -version и javac -version.

Другая распространенная причина в том, что файл поврежден во время передачи файлов (FTP) между различными машинами. Эта передача должна выполняться в двоичном режиме, а не в текстовом режиме.

Другой возможной причиной является аппаратная ошибка, например. поврежденный жесткий диск/файл/память. Попробуйте перекомпилировать или другую машину.

Answer 3

Чтобы уточнить: это происходит после того, как вы очистили все старые файлы .class и перекомпилировали их на одном компьютере?

Или вы компилируете на одном компьютере и затем копируете файлы в другой? Если это так, то, скорее всего, ваше программное обеспечение для передачи файлов искажает файлы (Windows < -> Linux является обычным преступником, чаще всего добавлением/удалением 0x0D байт, но иногда добавлением маркера OOS OOS OXA).

Я подозреваю, что если вы проверите свой процесс, вы обнаружите, что где-то вы изменяете файлы за пределами Java. Нет никакой причины - даже изменения версии - для файла, созданного действительным компилятором Java, чтобы иметь дополнительные байты в конце.

Answer 4

У меня была аналогичная проблема. Я просто попытался написать один класс на своем офисном ПК и перенести на наш клиентский сервер, чтобы проверить что-то <, потому что на этой машине не было JDK. Я использовал ту же версию java на обеих машинах, но после передачи я получил это исключение. Я пытался использовать архиватор перед передачей, и это помогло.

Answer 5

Я столкнулся с этим исключением только во время разработки. Мне кажется, что ECJ Eclipse (Eclipse Luna) вызывает такое поведение. Для меня чистая конструкция решила проблему.