Падение через switch
- case
можно достичь, не имея кода в case
(см. case 0
), или используя специальные goto case
(см. case 1
) или goto default
( см. case 2
) формы:
switch (/*...*/) {
case 0: // shares the exact same code as case 1
case 1:
// do something
goto case 2;
case 2:
// do something else
goto default;
default:
// do something entirely different
break;
}
Я часто сталкивался с этой проблемой, когда существовал сценарий (ant, maven, ...), который обрабатывал компиляцию XMLBeans, и другой механизм использовался для компиляции и выполнения остальной части кода. . Иногда одна часть удаляет сгенерированные файлы, которые XMLBeans ищет в вашей трассировке стека, но оставляет сгенерированные файлы Java XMLBeans, поэтому все будет компилироваться и выглядеть нормально.
Я также видел это при использовании опции вывода исходных файлов, но не файлов классов. Исходные файлы, отличные от Java, генерируются только непосредственно в папке класса или файле jar, созданном XMLBeans.
Я никогда раньше не пользовался этой библиотекой, но могу догадываться, что происходит. С этим квалификатором (т.е. я просто придумываю это, но прошло 7 часов, и никто больше ничего не придумал) ...
Заявление очевидного: что-то было где-то скомпилировано и не может быть загружено. Я не думаю, что это что-то есть в файле jar; Я предполагаю, что это один из ваших ресурсов, который был скомпилирован / кэширован в какое-то место.
Я бы предположил либо:
Вы что-то изменили (например, версию схемы?) Между компиляция и загрузка / запуск?
Можете ли вы удалить скомпилированную версию и перекомпилировать, а затем попробовать перезагрузить?
Можете ли вы найти скомпилированную версию в файловой системе?
Для этого вы можете попробовать
] grep "s2B8331230CBD98F4933B0B025B6BF726" `find.
из подходящего каталога.
Можете ли вы выполнить md5 для класса / ресурса, вызывающего проблемы как в среде компиляции, так и во время выполнения? Они совпадают?
Надеюсь, что-то внутри помогает или вызывает мысль.
Эти файлы классов создаются в каталоге resources/schemaorg_apache_xmlbeans. Я видел поведение xmlbeans, когда сгенерированный ant-скрипт не включал этот каталог в создаваемый jar (возможно, из-за ошибки?) Проверьте, был ли он включен в jar. Вы можете вручную пересобрать jar или проверить параметры командной строки генерации кода.