Инструменты анализа кода и объявления между типами

Question

У меня есть проект maven, сгенерированный Spring Roo, и я использую несколько инструментов (checkstyle, pmd и т. Д.) Для сбора информации о моем проекте. (именно для этого я использую сонар Codehaus )

Roo интенсивно использует AspectJ Inter объявления типов (ITD) для разделения проблем, таких как персистентность, javabeans-getter / setters и т. Д.

Эти ITD встроены во время компиляции, поэтому такие инструменты, как checkstyle и pmd (которые работают на уровне исходного кода), содержат много ложных срабатываний.

Единственное решение, которое я сейчас вижу, - это отключить проверки для Классов, использующих ITD.

Есть идеи получше?

Answer 1

Этот ответ не поможет вам прямо сейчас, но, надеюсь, он может вас заинтересовать, так как обещает решение вашей проблемы в ближайшем будущем. Я не знаю, знаете ли вы IntelliJ IDEA - Java IDE от JetBrains, но в этом направлении уже ведется работа, и вот ссылка на специальную проблему, которой вы, возможно, захотите следовать: http://youtrack.jetbrains.net/issue/IDEA-26959. Просто установить часы на него - и получать уведомления, когда функция реализована. IntelliJ IDEA обеспечивает действительно мощный SCA. Таким образом, поддержка ITD также должна быть высокого качества.

Answer 2

FindBugs и Cobertura работают НЕ на уровне источника, а на уровне байт-кода.Таким образом, вы должны поменять свои аспекты статически (что также улучшит время запуска приложения) во время компиляции (например, с помощью плагина maven AspectJ), а не во время загрузки, а затем запустить инструменты статического анализа для байт-кода результата.

Answer 3

Сомневаюсь, что это будет «нишевой проблемой» гораздо дольше :-) Надеемся, что поставщики инструментов рассмотрят необходимые улучшения.

Answer 4

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

Многие сторонники ткачества выполняют переплетение двоичного кода, потому что у них нет доступа к информации (таблица символов, имена, типы, типы выражений и т. Д.), Создаваемой интерфейсом компилятора. Итак, хак в том, что используйте код виртуальной машины, созданный компилятором (этот трюк в основном работает только для наборов команд VM, таких как .net IL и коды классов Java), который часто легко декодировать (хороший, обычный набор команд), украшенный информация таблицы символов.

Но если вы не можете рассуждать о бинарных результатах такого процесса ткачества, то вы не можете быть уверены, что тканая программа не глючит, что является точкой оригинального вопроса ОП: «Как я могу запустить инструменты SCA на (эффективном) тканом источнике? ".

Вы можете исправить это двумя способами:

• Заставьте сообщество писать инструменты SCA, которые обрабатывают байт-коды, а не исходный код. Это может быть сложно, поскольку исходный код может содержать информацию, потерянную в процессе компиляции.
• Лучшая идея: Заставить сообщество аспектистов писать сценаристы аспектов, которые работают с исходным кодом, и создавать исходный код. Это может быть сложно, потому что получить полный языковой интерфейс сложно.

Я не могу помочь вам сделать выбор сообщества.

Я могу оказать сильную поддержку, чтобы помочь сообществу выбрать второй путь: наш DMS Software Reengineering Toolkit . Это система преобразования программ, которая выполняет директивы в виде «если вы видите this , замените его на that », но соблюдая синтаксис и семантику языка, фактически применение таких изменений к структурам данных компилятора, созданным полноязычными интерфейсами. ( Это версия программного обеспечения эквационального замещения в математике ). Измененные структуры данных могут быть реэкспортированы как скомпилированный исходный текст с комментариями.

Если вы понимаете, что преобразования могут вообще делать, вы увидите, что сторонники ткачества являются частным случаем систем преобразования программ . Так легко реализовать ткачих аспектов с использованием DMS, и результаты исходный код, что означает Вы можете применять инструменты анализа исходного кода.

Я сомневаюсь, что это на самом деле решает проблему OP-анализа кода, сгенерированного Roo, в краткосрочной перспективе: - {

Answer 5

Не могли бы вы добавить специфичные для инструмента аннотации / комментарии к коду Java для подавления ложных срабатываний? Например, FindBugs имеет собственную аннотацию @SuppressWarnings.