Привет Хабр! Сегодня я хотел бы поговорить про динамическое компилирование и исполнение Java-кода, подобно скриптовым языкам программирования. В этой статье вы найдете пошаговое руководство как скомпилировать Java в Bytecode и загрузить новые классы в ClassLoader на лету.
Зачем?
В разработке все чаще возникают типовые задачи, которые можно было бы закрыть простой генерацией кода. Например, сгенерировать DTO классы по имеющейся спецификации по стандартам OpenAPI или AsyncAPI. В целом, для генерации кода нет необходимости компилировать и выполнять код в runtime, ведь можно сгенерировать исходники классов, а собрать уже вместе с проектом. Однако при написании инструментов для генерации кода, было бы не плохо покрыть это тестами. А при проверке самый очевидный сценарий: сгенерировал-скомпилировал-загрузил-проверил-удалил. И вот тут-то и возникает задача генерации и проверки кода "на лету".
Также иногда возникают потребности выполнять какой-то код удаленно. Как правило это какие-то распределенные облачные вычисления. В этом случае можно отправлять исходный код на вычислительный узел, а там уже происходит динамическая сборка и выполнение.
Последовательность действий
Для выполнения Java-кода в Runtime нам потребуется:
Динамически создать и сохранить наш код в .java файл.
Скомпилировать исходники в Bytecode (файлы .class).
Загрузить скомпилированные классы в ClassLoader.
Использовать reflection api для получения методов и выполнения их.
Шаг 1. Генерация кода
Вообще для генерации исходников можно конечно просто написать текст через StringBuider в файл и быть довольным. Но мне хотелось бы показать более прикладные решения, поэтому рассмотрим вариант генерации кода с использованием пакета com.sun.codemodel, а вот тут есть неплохой туториал по этому пакету. Так же на его основе есть библиотека jsonschema2pojo для генерации кода на основе jsonschema. Итак к коду:
public void generateTestClass() throws JClassAlreadyExistsException, IOException {
//создаем модель, это своего рода корень вашего дерева кода
JCodeModel codeModel = new JCodeModel();
//определяем наш класс Habr в пакете hello
JDefinedClass testClass = codeModel._class("hello.Habr");
// определяем метод helloHabr
JMethod method = testClass.method(JMod.PUBLIC + JMod.STATIC, codeModel.VOID, "helloHabr");
// в теле метода выводим строку "Hello Habr!"
method.body().directStatement("System.out.println(\"Hello Habr!\");");
//собираем модель и пишем пакеты в currentDirectory
codeModel.build(Paths.get(".").toAbsolutePath().toFile());
}
Пример выше сгенерирует класс Habr.java с одним методом:
package hello;
public class Habr {
public static void helloHabr() {
System.out.println("Hello Habr!");
}
}
Шаг 2. Компиляция кода
Для компиляции в Bytecode обычно используется javac и выполняется он простой командой:
javac -sourcepath src -d build\classes hello\Habr.java
Однако, нам надо скомпилировать наш класс прямо из кода. И для этого есть библиотека компилятора, до которой можно достучаться через javax/tools/JavaCompiler. Это реализация javax/tools/Tool (которая лежит в <JDK_HOME>/lib/tools.jar). Выглядеть это будет как-то так:
Path srcPath = Paths.get("hello");
List<File> files = Files.list(srcPath)
.map(Path::toFile)
.collect(Collectors.toList());
//получаем компилятор
JavaCompiler compiler = ToolProvider.getSystemJavaCompiler();
//получаем новый инстанс fileManager для нашего компилятора
try(StandardJavaFileManager fileManager = compiler.getStandardFileManager(null, null, null)){
//получаем список всех файлов описывающих исходники
Iterable<? extends JavaFileObject> javaFiles = fileManager.getJavaFileObjectsFromFiles(files);
DiagnosticCollector<JavaFileObject> diagnostics = new DiagnosticCollector<>();
//заводим задачу на компиляцию
JavaCompiler.CompilationTask task = compiler.getTask(
null,
fileManager,
diagnostics,
null,
null,
javaFiles
);
//выполняем задачу
task.call();
//выводим ошибки, возникшие в процессе компиляции
for (Diagnostic diagnostic : diagnostics.getDiagnostics()) {
System.out.format("Error on line %d in %s%n",
diagnostic.getLineNumber(),
diagnostic.getSource());
}
}
Шаг 3. Загрузка и выполнение кода
Для выполнения кода нам надо загрузить его через ClassLoader и через reflection api вызвать наш метод.
//получаем ClassLoader, лучше получать лоадер от текущего класса,
//я сделал от System только чтоб пример был рабочий
ClassLoader classLoader = System.class.getClassLoader();
//получаем путь до нашей папки со сгенерированным кодом
URLClassLoader urlClassLoader = new URLClassLoader(
new URL[]{Paths.get(".").toUri().toURL()},
classLoader);
//загружаем наш класс
Class<?> helloHabrClass = urlClassLoader.loadClass("hello.Habr");
//находим и вызываем метод helloHabr
Method methodHelloHabr = helloHabrClass.getMethod("helloHabr");
//в параметре передается ссылка на экземпляр класса для вызова метода
//либо null при вызове статического метода
methodHelloHabr.invoke(null);
Итог
В этой статье я постарался показать полноценный сценарий генерации и выполнения кода в Runtime. Самому мне это пригодилось при написании unit-тестов для библиотеки по генерации DTO классов на базе документации сгенерированной библиотекой springwolf. Реализацию тестов в моем проекте можно посмотреть тут.
Комментарии (8)
ksbes
16.09.2022 14:02+11) Зачем всё это писать на диск, когда можно компилировать из памяти ?
2) Зачем передавать удалённо код, когда можно сразу передавать удалённо байт-код? Для чего Java в общем-то и затачивалась с середины 90-х.
Да и вообще — я написал много сотен тысяч строк (наверное — не считал) на Java и C# — и копоративные, и игровые, и банковские, и просто, но мне ни разу не пришлось сталкиваться с задачей самостоятельной кодогенерации. Точнее вру — один раз пришлось (ещё джуном), но это была генерация кода PHP на C# и TSQL (совместно) — и тот проект ожидаемо утонул не дойдя до стадии даже альфы.
Что я делаю не так? Не самым странным образом выстраиваю процесс разработки и архитектуру?stepanovD Автор
16.09.2022 14:16+1Спасибо за замечание. Конечно можно компилировать из памяти, но если вы хотите все таки генерировать код, который сможете глазами посмотреть и добавить в git, то без сохранения никак. А так, да, в общем случае не важно где хранится исходник.
А вот при удаленных вычислениях довольно важно передавать исходный код или bytecode. У Java нет прямой совместимости, поэтому если на стороне клиента собирать bytecode в версии выше чем на узле, то будут проблемы. В этом случае надежнее передавать именно исходники, для исключения зависимостей в версиях Java между клиентом и узлом.
Artyomcool
17.09.2022 09:40Вы говорите странное. Вы можете компилировать "новыми" инструментами код со "старым" таргетом. И вы и так знаете версию на узле, которую поддерживаете, потому что используете/не используете соответствующие языковые фичи и библиотеки.
imanushin
16.09.2022 18:52У меня была похожая статья, но с другим JVM языком - https://habr.com/ru/company/dbtc/blog/505162/ .
exadmin
17.09.2022 13:46Сколько раз сталкивался с кодо-генерацией - это всегда боль поддержки, jsp можно туда же отправить, но это хоть какой-то стандарт. Единственный сценарий я нашёл, где такое обосновано - песочница для проверки тестовых заданий, а-ля codewars.
kpmy
17.09.2022 15:02Java Eclipse Compiler кажется справляется с этим поудобнее, даже в JRE (querydsl как пример).
qideil
18.09.2022 15:26Кодогенерация придумана очень давно, тем более для таких простых вещей как DTO. Тем более, когда у вас есть «стандарты». Посмотрите в сторону XSLT. Простейший DTD и шаблон в XSL решает все проблемы. Если же вам нужна версионность, и вы не хотите перезагружать JVM, то стоит посмотреть на OSGi — проверенный временем механизм. Ну или gRPC, если уж совсем нужно быстро. И да, передавать сорцы или байткод с последующей подгрузкой на сервере — огромная дыра в безопасности.
sparhawk
Спасибо за труд, показали, что кодогенерация в Java — это боль. Правда, она не часто требуется. Подобный код всегда write-only, в нем не разобраться и очень сложно его развивать.
Пока нашел только один нормальный способо кодогенерации в мире JVM — создание классов из функций Clojure через gen-class. В чем-то он даже логичен — логика пишется в виде функций Clojure, потом прикручиваем поля класса, аннотации и прочюю ненужнную с т. з. функциональщика фигню.
Единственное, Clojure может поначалу испугать не видавшего обширный мир айти разработчика, но надо же расширять кругозор.