Инструменты анализа кода и Inter-Type-Declarations
У меня есть проект maven, созданный Spring Roo и использующий несколько инструментов (checkstyle, pmd и т.д.) для сбора информации о моем проекте. (а именно, я использую сонар кодерах для этого)
Roo активно использует объявления типа AspectJ Inter Type (ITD), чтобы разделять такие проблемы, как сохранение, javabeans-getter/seters и т.д.
Эти ITD сотканы во время компиляции, поэтому инструменты, такие как checkstyle и pmd (которые работают на исходном уровне), имеют множество ложных срабатываний.
Единственное решение, которое я сейчас вижу, - деактивировать проверки для классов, которые используют ITD.
Любые лучшие идеи?
Ответы
Ответ 1
Этот ответ не поможет вам прямо сейчас, но, надеюсь, это может вас заинтересовать, поскольку это решение promises для вашей проблемы в ближайшем будущем.
Я не знаю, знаете ли вы IntelliJ IDEA - Java IDE от JetBrains, но в этом направлении уже выполняется работа, и вот ссылка на выделенную проблему, которую вы можете захотеть: http://youtrack.jetbrains.net/issue/IDEA-26959. Просто установите часы на него - и получите уведомление, когда функция реализована.
IntelliJ IDEA обеспечивает действительно мощный SCA. Таким образом, поддержка ITD также должна быть высокого качества.
Ответ 2
Сомневаюсь, что это будет "проблема ниши" гораздо дольше:-)
Хотелось бы надеяться, что поставщики инструмента будут смотреть на необходимые улучшения.
Ответ 3
Если вы хотите объяснить исходный код после того, как аспекты были вплетены в код, вы должны вставлять аспекты в исходный код, а не в двоичный код.
Многие сторонники ткачества выполняют двоично-кодовое переплетение, потому что у них нет доступа к информации (таблица символов, имена, типы, типы выражений и т.д.), создаваемые передним коннектором компилятора. Итак, взломать, используйте код виртуальной машины, созданный компилятором (этот трюк в основном работает только для наборов команд VM, таких как коды .net IL и java), которые часто легко декодировать (красивый, регулярный набор команд), украшенный информация таблицы символов.
Но если вы не можете рассуждать о бинарных результатах такого процесса ткачества, то вы не можете быть уверены, что сплетенная программа не глючит, что является точкой исходного вопроса OP: "Как я могу запустить инструменты SCA на (эффективном) тканом источнике?".
Вы можете исправить это двумя способами:
- Попросите сообщество написать инструменты SCA, которые обрабатывают байтовые коды, а не источник. Это может быть сложно, потому что исходный код может содержать информацию, потерянную в процессе компиляции.
- Лучшая идея: Получите сообщество аспект, чтобы писать аспектные ткачи, которые работают с исходным кодом, и создают исходный код. Это может быть сложно, потому что полное заполнение языковых интерфейсов затруднено.
Я не могу помочь вам сделать выбор сообщества.
Я могу предложить сильную поддержку, чтобы помочь сообществу выбрать второй способ: наш DMS Software Reengineering Toolkit. Это система преобразования программ, которая выполняет директивы формы "если вы видите это, замените ее на это", но соблюдая синтаксис и семантику языка, фактически применяя такие изменения к структурам данных компилятора, созданным с помощью полного языкового фронта заканчивается. (Это программная версия эквациональной замены в математике). Измененные структуры данных могут быть реэкспортированы как компилируемый исходный текст с комментариями.
Если вы понимаете, какие преобразования могут делать в целом, вы можете увидеть, что аспекты ткачества являются особым случаем систем преобразования программ. Итак, легко
для реализации аспектных ткачей с использованием DMS, а результаты - это исходный код, что означает
вы можете применить инструменты анализа исходного кода.
Я сомневаюсь, что это фактически решает проблему OPs анализа Roo-сгенерированного кода в краткосрочной перспективе: - {
Ответ 4
Оба FindBugs и Cobertura НЕ работают на исходном уровне, но на уровне байт-кода. Таким образом, вы должны волноваться в ваших аспектах статически (что также улучшит время запуска приложения) во время компиляции (например, с использованием плагина maven AspectJ), а не во время загрузки, а затем запускать инструменты статического анализа в байт-коде результата.
Ответ 5
Не могли бы вы добавить аннотации/комментарии к конкретным приложениям в код Java для подавления ложных срабатываний? Например, FindBugs имеет собственную аннотацию @SuppressWarnings.