java.lang.ClassFormatError: дополнительные байты в конце файла класса - PullRequest
9 голосов
/ 15 июня 2010

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

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

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

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

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

Ответы [ 5 ]

7 голосов
/ 15 июня 2010

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

Файл class не должен быть усечен или иметь дополнительные байты в конце.

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

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

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

2 голосов
/ 05 марта 2015

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

2 голосов
/ 18 июня 2010

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

К сожалению, с моей стороны произошел сбой, поскольку тестирование междуно, по крайней мере, это работает.

Короче говоря:

-Линейные каналы неверны И Правильно присваивайте имена файлам (стандарты Java, а не стандарты ОС)

2 голосов
/ 15 июня 2010

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

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

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

0 голосов
/ 23 января 2015

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...