Я написал процессор аннотаций клиентов для создания различных исходных файлов, заключенных в плагин Eclipse. В рамках этого процесса он также регистрирует различные ошибки и предупреждения, используя обычный вызов ProcessingEnvironment#getMessager().printMesssage(Kind, String, Element)
.
Я тестировал процессор, отлаживая плагин в Eclipse. В запущенном субэкземпляре Eclipse процессор все работает должным образом - исходные файлы генерируются, подбираются и интерпретируются компилятором по желанию. Любые ошибки компилятора (т. Е. Нестандартные) в сгенерированных и несформированных, как и ожидалось, появляются в редакторе, в представлении «Проблемы» и т. Д.
Однако я вижу много несоответствий в том, как появляются настраиваемые ошибки и предупреждения. Я наблюдаю следующее поведение:
- Если элемент не указан, все сообщения появляются в журнале ошибок под типом «Информация», независимо от типа, указанного при регистрации ошибки.
- Если сообщение имеет тип
NOTE
, оно всегда отображается в журнале ошибок под типом «Информация», независимо от того, указан ли элемент. - В противном случае, если указан элемент, ошибки и предупреждения периодически появляются в представлении «Проблемы» и в редакторе; иногда они нигде не появляются. Они никогда не появляются в журнале ошибок, независимо от того, является ли тип
ERROR
илиWARNING
.
Как было сказано выше, настоящая проблема - это пункт 3: в определенных ситуациях я просто не могу заставить ошибки отображаться в редакторе, несмотря на то, что я зарегистрирован для допустимых элементов. Фактически, мне удалось надежно сделать так, чтобы ошибки появлялись, а не появлялись, просто изменяя имя определенного сгенерированного исходного файла.
Конечно, проблема не в самом имени файла, но, безусловно, в том случае, когда создание класса с именем, которое соответствует ссылкам, уже содержащимся в коде, вызывает скрытие ошибок, в то время как генерация его с другим именем (или вообще без него) вызывает ошибки. чтобы показать (а также все обычные ошибки компилятора, вызванные отсутствием класса). Самым странным является то, что в этом сгенерированном классе нет ничего принципиально отличного от любого из других (которых много), хотя он уникален по своей структуре и способам обращения к нему. Он также достаточно длинный (около 400 методов), но искусственное его сокращение не имело никакого значения. Другие сгенерированные классы также имеют существующие ссылки в коде и не подавляют ошибки.
К сожалению, у меня еще не было времени проверить, возникает ли эта проблема при развертывании подключаемого модуля Eclipse (т. Е. При запуске в «реальном» экземпляре Eclipse), или действительно, если проблема возникает при явном вызове javac
или вызове сборки Maven.
Не публикуя полный код плагина, я не ожидаю, что кто-то сможет помочь напрямую, но я очень открыт для любых предложений или советов, если у кого-то возникнут проблемы с ошибками, сгенерированными процессором аннотаций. Мне кажется, что это ошибка в Eclipse, но я не смог найти в Интернете ссылки на нее. Я также не могу найти никаких ошибок в файлах .metadata / .log базового экземпляра Eclipse или запущенного суб-экземпляра Eclipse. Наконец, я удостоверился, что в коде обработчика аннотаций нет исключений, подавленных или сообщенных.
Подробная информация о версии Eclipse:
Version: Luna Service Release 1a (4.4.1)
Build id: 20150109-0600
Любая помощь приветствуется и заранее большое спасибо :)
new Throwable("debug message").printStackTrace()
в качестве оператора отладки в различных частях кода обычно начинается с того места, где я не могу понять ничего другого. - person Marco   schedule 21.10.2015