Проект шлюза Springboot, написанный на Groovy, т. е. все контроллеры и службы находятся в *.groovy.
Фактически, код полностью выполнен в стиле Java. Использование groovy предназначено только для горячего обновления. Поэтому нам не нужна динамическая функция groovy.
Но благодаря динамической особенности groovy, несмотря на некоторые ошибки в коде, проект может пройти стадию компиляции и запуститься. Об ошибке не сообщается до тех пор, пока не будет вызван определенный контроллер. Типы ошибок кода просты, например:
Вот демо:
сервисный код
@Service
public class DemoServiceImpl implements DemoService {
@Override
public void serviceMethod() {
System.out.println("hello");
}
}
код контроллера
@RestController
public class DemoController {
@Autowired
private DemoService demoService;
@RequestMapping("/path")
public Integer controllerMethod() {
// unexisted method in service
demoService.serviceMethod222();
char c = 'c';
// unexisted variable in service
System.out.println(c222);
// declared type doesn't match return type
int a = new Date();
// return type also not match
return "hahaha";
}
}
На самом деле, @TypeChecked или @CompileStatic могут полностью удовлетворить мои потребности. Однако мой руководитель не позволяет мне добавлять аннотации к каждому классу.
Сейчас я подумываю об использовании какого-нибудь плагина maven, но понятия не имею.
Я слышал об AST и пытаюсь написать отличный сценарий, например:
Демонстрация сценария AST
@GroovyASTTransformation
class MyASTTransformation implements ASTTransformation {
@Override
void visit(ASTNode[] nodes, SourceUnit source) {
// When I write this, can I see the error at compile?
source.addError("should report error!")
}
}
Но я не знаю, как заставить скрипт работать при компиляции и какая должна быть логика скрипта?
Итак, мои вопросы:
Вы можете включить любой из них по умолчанию в настройках компилятора:
Обычно классы в Groovy компилируются с использованием динамической среды выполнения. Ты можешь активируйте статическую компиляцию, поместив аннотацию с именем
@CompileStatic
на любой класс. Некоторые люди хотели бы, чтобы этот режим был активирован по умолчанию. то есть нет необходимости аннотировать (потенциально многие) классы. С использованиемconfigscript
, делает это возможным. Прежде всего, вам необходимо создать файл названныйconfig.groovy
в скажемsrc/conf
со следующим содержанием:withConfig(configuration) { ast(groovy.transform.CompileStatic) }
Это описывает общий подход; интеграция компилятора groovy в В build-tools обычно есть способ это установить.
В тех местах, где вы не хотите его использовать, вы можете отказаться, добавив аннотацию с помощью
@CompileDynamic
.
Спасибо большое, действительно работает!!! Затем я обнаружил еще одну проблему. Конфигурация CompileStatic сообщает о множестве ошибок, включая необъявленные переменные и методы, которые меня действительно беспокоят. Однако из-за статической проверки также сообщается о некоторых других ошибках. Например: 1. Класс DTO без аннотации lombok @Data, при этом вызываются методы получения и установки. 2. Для параметра требуется тип «Object», но мы указываем «String». Это означает: CompileStatic слишком строг для меня. Мне нужно только проверить, использовали ли мы необъявленные переменные или методы. Интересно, как можно настроить скрипт?
Если проверка типов слишком строга для вас, у вас есть варианты частичного воспроизведения или расширения проверки типов. Я не советую первый вариант, это черная дыра для вашего времени на разработку... ну, если вы, конечно, действительно не готовы вкладывать много времени. Второй вариант описан здесь: https://docs.groovy-lang.org/docs/groovy-4.0.22/html/documentation/#_type_checking_extensions Расширение проверки типов не только позволяет динамическому коду проходить статическую компиляцию путем пользовательского разрешения, но вы также можете сделать код динамическим.
На самом деле существует возможный вариант 3. вы можете использовать @CompileDynamic для методов, которые вы хотите, чтобы средство проверки статического типа игнорировало. Но я полагаю, что ваш лидер не разрешает @CompileStatic
искренне спасибо! Я бы хотел выбрать второй вариант — расширение проверки типов. Ваше предположение верно. Мой руководитель не разрешает никаких попыток использования исходного кода.... Это мне очень помогает! Еще раз спасибо тебе, мой герой!
Не могли бы вы добавить интеграционные тесты?