Статьи

FindBugs и PMD, применяемые в Java EE 5

Март 17, 2019

После нескольких месяцев увлекательного обучения — написания первых WSDL-веб-сервисов на основе EJB 3 и JPA — я нашел время, чтобы включить в мой проект автоматизированные задачи по качеству с помощью скриптов Ant для FindBugs и PMD. Как и ожидалось, первый раунд проверки качества дал мне длинный список ошибок, большинство из которых были тривиальными ошибками, такими как непубличные поля или неиспользованные методы. После первой очистки в отчете остались некоторые ошибки, и после нескольких циклов проверки качества я получил ряд хитрых ошибок — тех, которые вы не можете себе представить, и тех, которые определенно не кажутся ошибками. В следующих разделах я расскажу об этих хитрых ошибках и способах их устранения. Я надеюсь, что вы согласны с моей стратегией, и я был бы признателен за отзыв, если вы не согласны.

Зачем использовать PMD и FindBugs?

Хорошей отправной точкой для обеспечения качества программного обеспечения является проверка того, работает ли код, как задумано, что можно сделать с помощью тестирования программного обеспечения . Несмотря на полезность тестов, они дают вам только хороший индикатор того, что код выполнит свою работу, но тесты упускают из виду пункт о детальной проверке кода (покажите мне код). Используете ли вы правильный синтаксис и структуры данных? Есть ли избыточность в коде?

Анализ правильности кода требует, чтобы человек помнил все детали о языке Java , следя за настройкой производительности — невыполнимая задача, если пытаться вручную. К счастью, такие инструменты, как PMD и FindBugs, помогают находить проблемы с кодом, а также предлагают полезные советы по оптимизации кода — эти инструменты раскрывают большинство общих проблем с кодом, экономя ваше время на более важных задачах. Если вы никогда раньше не использовали эти инструменты или не обращали на них должного внимания, вы можете предположить простую цель: цель состоит в том, чтобы минимизировать количество сообщений об ошибках в вашем коде. Чем ближе вы подойдете к отчету об отсутствии ошибок, тем лучше будет ваш код, Да, он линейный, с некоторой интерпретацией из-за различных уровней и типов ошибок, охватываемых автоматизированными инструментами (имейте в виду, что инструменты не думают, они — неназванные роботы). Установка и настройка PMD и FindBugs полностью используются в Интернете, и вместо публикации еще одного блога об этом я кратко прокомментирую недавние эксперименты, которые мы провели в проекте Cejug-Ads .

Применение PMD и FindBugs к проекту Cejug-Ads

Cejug-Объявления — это приложение J2EE с открытым исходным кодом, основанное на WSDL-первых веб-сервисах, EJB 3 и JPA, что означает проект, полный сгенерированного кода , аннотаций и обобщений, сгенерированных wsimport . Сочетание этих современных функций и технологий Java породило противоречивые ошибки в отчетах, но сначала давайте проверим код и запустим инструменты качества. Важная деталь в нашей задаче о муравьях — это зависимость от Glassfish . Поскольку наш проект зависит от типов и аннотаций J2EE, переменная окружения AS_HOMEдолжна присутствовать в вашей операционной системе, чтобы позволить вам выполнить задачу компиляции кода.

small_phantom.png

 

 

 

 

 

 

Надпись: Phantom Blot предпочитает интеллектуальные игры FindBugs

 

Шаги для проверки кода и запуска задач качества:

  1. Установите Glassfish и настройте переменную средыAS_HOME
  2. Оформить заказ код из репозитория SVN : 
    svn checkout https://cejug-classifieds.dev.java.net/svn/cejug-classifieds/trunk cejug-classifieds --username your.java.net.login
  3. После подключения хранилища, пожалуйста, ознакомьтесь с модулем cejug-adss-server , который я буду использовать в качестве примера.
  4. Запустите задачи качества муравья: 
    ant server,pmd,FindBugs

Задачи ant генерируют два отчета, которые вы можете найти в папке /build/quality— это стандартные отчеты PMD и FindBugs. Другая важная деталь: FindBugs потерпит неудачу в случае любой ошибки, поэтому успешное выполнение задачи означает чистый код относительно FindBugs. PMD еще не на 100% чист, потому что в отчете есть нерешенные вопросы, о которых я расскажу ниже.

Специальные советы для пользователей IDE: проект предварительно настроен для Eclipse и IDE NetBeans, но его также можно скомпилировать и протестировать из линейных команд, если вы предпочитаете этот способ.

Настройка требуется для получения кода с нулевыми ошибками в соответствии с FindBugs

  1. Изменение XMLGregorianCalendar на Calendar : WSIMPORT использует JAXB для генерации классов из документов схем XSD, и по умолчанию JAXB генерирует XMLGregorianCalendar из xsd:dateTimeопределения атрибутов. Поскольку XMLGregorian календарь не является сериализуемым типом, FindBugs жалуется на это. Мы можем обойти это путем применения настройки JAXB в наших документах XSD, как описано в этой ссылке.

     <xsd:annotation>
           <xsd:appinfo>
              <jaxb:globalBindings>
                 <jaxb:javaType name="java.util.Calendar"
                    xmlType="xsd:dateTime"
                    parseMethod="javax.xml.bind.DatatypeConverter.parseDate"
                    printMethod="javax.xml.bind.DatatypeConverter.printDate" />
              </jaxb:globalBindings>
           </xsd:appinfo>
        </xsd:annotation>

     

  2. Удаленный интерфейс @EJB требует Serializable классов : WSIMPORT генерирует несериализуемый код из документов WSDL, но, поскольку я использую интерфейсы @Remote EJB, сообщения RMI требуют, чтобы их содержимое было Serializable. Обходной путь это снова была еще одна аннотация в схеме XSD:

 

    <xsd:annotation>
       <xsd:appinfo>
          <jaxb:globalBindings>
             <xjc:serializable uid="-6026937020915831338" />
             <jaxb:javaType name="java.util.Calendar"
                xmlType="xsd:dateTime"
                parseMethod="javax.xml.bind.DatatypeConverter.parseDate"
                printMethod="javax.xml.bind.DatatypeConverter.printDate" />
          </jaxb:globalBindings>
       </xsd:appinfo>
    </xsd:annotation>

 

И это все, после этих незначительных изменений FindBugs прекратил беспокоить меня об ошибках, и я получил мой 100% чистый код после FindBugs, включая сгенерированный код. FindBugs проверяет байт-код ваших классов, он использует более сложную стратегию проверки того, как работает ваш код, а не как он написан как .javaдокумент. Чистый код FindBugs указывает на то, что сгенерированный байт-код является надежным — это хорошее чувство для разработчиков и лучшее время для сна для руководителей проектов.

Настройка необходима для получения кода с нулевыми ошибками в соответствии с PMD

PMD было немного сложнее удовлетворить, поскольку он основан на анализе кода Java, а не на байт-коде. Немного более педантичный, чем FindBugs, PMD основан на эвристике статистики кода. Если код длинный, PMD предполагает, что он содержит ошибки, и если существует слишком много открытых методов, PMD также предполагает, что он содержит ошибки. Это попытка определить проблемы , анализируя метрики коды является спорной , но PMD был один из первых инструментов качества я научился использовать несколько лет назад, так что я решил изменить свои правила , установленные для того , чтобы продолжать использовать его в моем J2EE 5 кода. Вы можете найти результирующий файл конфигурации набора правил здесь . Помните, что Cejug-Ads находится в стадии разработки, и содержание этого файла — только наши убеждения в отношении качества нашего собственного кода .

small_beagleboys.png
Надпись: Beagle Boys предпочитают грубую силу против жуков.

После настройки PMD я получил отчет с нулевыми ошибками, но поскольку PMD охватывает пять различных уровней проблем, я заметил отчет о некоторых высоких предупреждениях в коде. Я все еще борюсь с ними, особенно со следующими:
  1. BeanMembersShouldSerialize : это сложно, так как у меня есть вторичная проблема, связанная с этим предупреждением. Один из графических интерфейсов, использующих наши сервисы, использует FLEX, и кажется, что FLEX использует отражение для установки значений в Java-бинах. Проблема в том, что JAXB не генерирует settersметоды для атрибутов, которые содержат maxOccurs='unbounded'(Коллекции). Это вызывает проблемы использования FLEX сервиса SOAP 1.1, предоставляемого JAXWS, и мы все еще ищем решение для этого. На самом деле, предупреждение PMD указывает на другое направление, но оно сохраняет полезную отметку о проблеме FLEX в нашем сервисном коде.

  2. AvoidFieldNameMatchingTypeName : один из элементов моего XSD имеет refк себе, потому что он моделирует Категории и Подкатегории. Поскольку я использую ссылку вместо создания нового атрибута, имя поля компилируется как то же имя класса. Я согласен с PMD, что это странно, поэтому я буду искать решение как можно скорее. Пока не найдено решение, предупреждение останется активным.

  3. AbstractClassWithoutAbstractMethod : поскольку мы используем постоянный фасад JPA, мы используем класс AbstractEntity для совместного использования полей сущностей. У этого класса нет никакого метода, поскольку он используется только как суперкласс для сущностей и поэтому не имеет никакого смысла заставлять этот класс быть конкретным или иметь методы.

  4. UncommentedEmptyConstructor : Я наконец решил удалить это правило, поскольку JAXB генерирует пустой конструктор для всех элементов в метаданных. На мой взгляд, ничего страшного, пустые конструкторы в большинстве случаев бесполезны, но они никогда не вызывают проблем, поэтому правило кажется слишком педантичным, чтобы оставаться активным.

  5. UnneededParentheses : так же, как и в предыдущем примере, ненужные круглые скобки не наносят ущерба коду, так как они будут удалены компилятором. Это происходит только в сгенерированных классах и не должно быть частью серьезного анализа кода.

Вывод: я настоятельно рекомендую вам использовать PMD и FindBugs в вашем коде J2EE 5

Генерируемый код и особенно Generics требует дополнительных усилий для прохождения анализа кода, поскольку это не чисто классический код Java. Специально PMD требует большего внимания, поскольку он основан на эвристике, а не на анализе байтового кода, и он старше, чем FindBugs. Многие предположения, управляемые PMD, были созданы до того, как дженерики поддерживают Java, а некоторые просто больше не применяются. Несмотря на это, мы поняли в наших экспериментах, что оба инструмента могут использоваться вместе с хорошими результатами и никакого конфликта вообще. Если вы не используете PMD и FindBugs в своем проекте, попробуйте их сегодня — вы удивитесь, насколько быстро вы сможете улучшить качество своего кода. На самом деле, держу пари, что вы также получите зависимость от их показателей качества, особенно FindBugs.

Признание: эксперименты и усилия по достижению текущих качественных результатов были переданы Родриго Лопесу , одному из главных комментаторов Cejug-Ads.

39
Share: