Пользовательский валидатор для статического использования рефлекса против пользовательского правила в SonarQube (Java, Eclipse)

Question

Возможно, возникли некоторые связанные вопросы, но я думаю, что моя ситуация достаточно своеобразна, чтобы обосновать вопрос самостоятельно.

Я работаю над исторически растущим огромным проектом Java (гораздо более миллиона LOC, из-за других причин, по которым мы все еще привязаны к Java 6 на данный момент), где отражение используется для отображения данных в таблицах - отражение не используется для динамического изменения отображаемых данных, а просто для использования каких-либо коротких сокращений кода. Упрощенная часть кода выглядит так.

TableColumns taco = new TableColumns(Bean.class); 
taco.add(new TableColumn("myFirstMember")); 
taco.add(new TableColumn("mySecondMember")); 
... 
List<Bean> dataList = getDataFromDB(myFilterSettings); 
taco.displayTable(dataList); 

Таким образом, значения ячеек таблицы каждой строки хранятся в экземпляре Bean. Значения для первой ячейки поступают от вызова itemOfDataList.getMyFirstMember() (так что здесь идет часть отражения кода). Обработка ячеек таблицы выполняется в зависимости от типа возврата itemOfDataList.getMyFirstMember().

Таким образом, легко добавить новые столбцы в таблицу, получив их стандартным образом, не заботясь о каких-либо деталях.

Проблема такого подхода: при изменении имени геттера компилятор не замечает и будет исключение во время выполнения в случае, если Bean.getMyFirstMember() был переименован в Bean.getMyFirstMemberChanged().

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

Моя цель: имеет валидатор, который будет проверять во время компиляции, существуют ли необходимые методы получения в классе Bean.

Возможные solultions:

• изменения кода (используя более конкретные Infos, написание адаптера, с помощью аннотаций или независимо от того, что могут быть проверены во время компиляции компилятором), я явно не хотят решения такого рода, из-за огромного кода. Я просто должен гарантировать, что отражение не будет терпеть неудачу во время выполнения.

• писать пользовательский валидатор: Я предполагаю, что это не должно быть слишком сложным, но у меня нет реальной идеи, как не начать, мы используем затмение, как язь, поэтому оно должно быть возможным, чтобы написать такой пользовательский валидатор - любые подсказки для хорошей отправной точки? Валидатор должен показать предупреждение в затмении, если parameter в TableColumn(parameter) не является final (должен быть буквальным или постоянным). Валидатор должен показывать ошибку в затмении, если TableColumn добавлен к TableColumns, а соответствующий Bean.getParameter() не существует.

• , как мы используем SonarQube для проверки качества, мы могли бы также реализовать пользовательские правила проверки, если методы действительно существуют - не совсем уверен, что если такой обычай правила можно (наверное да)

• возможно другие решения, которые дают быструю обратную связь в затмении, что некоторые таблицы не будут отображаться правильно после того, как некоторые методы геттерных были переименованы

что я прошу:

• Что будет проще в этой ситуации: написать пользовательский валидатор для затмения или написать собственное правило для SonarQube?

• подсказки, где начать любой подход

• намеков на другой solultions

Спасибо за вашу помощь.

Answer 1

Некоторых альтернатив:

1. Вы могли мигрировать в более современную Java для этой модели, он является главным кандидатом для ссылок метода. Затем ваша IDE выбора может автоматически позаботиться о проблеме при рефакторе/переименовании. Это можно сделать поэтапно, поскольку возникает необходимость/необходимость.
2. Вы можете написать свои собственные аннотации:.
   • Что вы, вероятно, может получить SonarQube для сканирования
   • Что может позволить вам воспользоваться javax.validation * лакомства, так что ваш код может выглядеть/чувствовать больше похоже на «стандартный» Java EE-код.
   • Аннотации могут быть покрыты процессором во время этапа сборки, у различных инструментов сборки есть способы связать это - и процессор может сделать более сложную/дорогостоящую интроспекцию, чтобы вы могли подталкивать валидацию к времени компиляции, а не запускать -время.