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

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

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

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

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

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

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

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

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

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

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

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

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

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