Краткий ответ :
Пока вы не используете старую Java версию <= 7, в которой отсутствует исправление для этой <a href="https://bugs.openjdk.java.net/browse/JDK-4879507" rel="nofollow noreferrer"> ошибки и как пока вы не используете собственный ClassLoader, CR C каждой записи zip в файле JAR проверяется, когда JAR загружается из пути к классам.
Длинный ответ (например для Java 8, мне не известны какие-либо известные ошибки регрессии в более новых версиях Java):
Java URLClassLoader (системный загрузчик классов по умолчанию в Java 8) использует класс sun.net / www/protocol/jar/JarURLConnection для чтения файлов JAR с URL-адресов.
Этот класс использует sun / net / www/protocol/jar/URLJarFile, который является подклассом java / util / zip / ZipFile . Этот класс вызывает метод чтения java / util / zip / ZipInputStream для чтения записей zip.
Класс ZipInputStream проверяет CR C для несжатых записей Zip здесь и для сжатых записей ZIP здесь . В случае поврежденной записи zip (есть CR C для каждой записи Zip, а не для всего ZIP-файла) генерируется исключение ZipException.
Вы получаете java .lang.NoClassDefFoundError потому что файл JAR не может быть загружен. Раньше должна быть ошибка. Я не проверял обработку ошибок, но я предполагаю, что ZipException где-то улавливается и регистрируется или, возможно, добавляется в качестве причины для NoClassDefFoundError. Поскольку вы не передаете свой JAR-файл или выводите какие-либо ошибки, его трудно проверить. Другая возможность заключается в том, что пропускается только одна поврежденная ZIP-запись, а другие загружаются - у меня не было времени углубиться в обработку ошибок, если вам интересно, взгляните на нее, я связал все упомянутые классы с источником код.