Перестаём бояться генерировать байт-код
https://t.me/ai_machinelearning_big_dataМногие, возможно, думают, что работа с байт-кодом Java (будь то чтение или, тем более, генерация) — это какая-то особенная магия, доступная только продвинутым разработчикам с особенно крутым опытом. На самом деле, я считаю такую точку зрения ошибочной. JVM устроена гораздо проще, чем CPU; она оперирует такими высокоуровневыми понятиями как классы, интерфейсы, методы, а не просто лопатит байты в памяти. В отличие от CPU, который легко уронить криво сгенерированным машинным кодом, JVM заботливо отверифицирует любой байт-код и в общем не даст выстрелить в ногу.
Но с чего начать погружение в байт-кодную магию? В сети есть некоторое количество туториалов по этому вопросу. Как мне кажется, они либо показывают слишком простые случаи, от которых непонятно, как перейти к чему-то более интересному, либо очень основательные и требуют вникать в теорию, собирать целиком картину в голове по кусочкам. Я хотел бы попробовать внести свой вклад в эту тему — надеюсь, у меня получится показать, как можно побороть первый страх и написать что-то похожее на реалистичный сценарий без особого вникания в теорию на первом этапе.
Весь приведённый код доступен в моём репозитории.
Задача
Я вдохновился книгой Бьёрна Страуструпа, по которой лет 20 назад изучал C++. В одной из первых глав в качестве задачи для введения в язык предлагается написать калькулятор выражений. Я же предлагаю не вычислять выражения, а генерировать байт-код, который вычисляет выражения.
Итак, формулировка: необходимо написать метод, которые принимает на вход строку с математическими выражениями и выдаёт на выходе экземпляр такого интерфейса:
public interface Expression {
double evaluate(Function<String, Double> inputs);
}
Выражения в списке разделены точкой с запятой (;), метод evaluate возвращает результат вычисления последнего из выражений. Выражения определим так:
- Число (например,
2,42,3.14) — это выражение. - Идентификатор (например,
foo,pi,myVar_1) — это выражение. Значение по-умолчанию для переменной вычисляется с помощью вызоваinputs.apply(id). - Если A и B — выражения, то A + B, A - B, A * B, A / B, -A, (A) — так же выражения
- Если A — это идентификатор, и B — это выражение, то A = B — так же выражение
Генерируем класс
Для начала напишем генератор класса, реализующего интерфейс Expression. Для этого вначале нужно подключить библиотеку ASM (кстати, документация по ней — это отличный мануал ещё и по байт-коду). В Gradle это может выглядеть так:
dependencies {
implementation "org.ow2.asm:asm:9.5"
implementation "org.ow2.asm:asm-util:9.5"
}
Теперь напишем заготовку нашего генератора:
public class ClassGenerator {
// Имя генерируемого класса. В принципе может быть любым.
public static final String CLASS_NAME = ClassGenerator.class.getName()
+ "$Generated";
// Имя сгенерированного класса, в терминах JVM.
// В JVM в качестве разделителя пакетов используется / вместо .
private static final String CLASS_INTERNAL_NAME =
CLASS_NAME.replace('.', '/');
public byte[] generate(String expr) {
// Точка входа в ASM - ClassWriter.
// Собственно, он и генерирует байт-код.
var cw = new ClassWriter(ClassWriter.COMPUTE_FRAMES
| ClassWriter.COMPUTE_MAXS);
// Добавляем вывод дизассемблированного байт-кода в консоль
ClassVisitor cv = cw;
if (Boolean.getBoolean("konsoletyper.exprbc.log")) {
cv = new TraceClassVisitor(cv, new PrintWriter(System.out));
}
// Создаём класс
cv.visit(
Opcodes.V11, // Версия JVM
Opcodes.ACC_PUBLIC, // модификаторы (public)
CLASS_INTERNAL_NAME, // имя класса (в терминах JVM)
null, // generic сигнатура, нам не нужна
Type.getInternalName(Object.class),
// имя родительского класса
// в Java можно не указывать extends Object,
// однако в JVM нужно всё указывать явно
// и предельно скрупулёзно
new String[] { Type.getInternalName(Expression.class) }
// имена реализуемых интерфейсов
);
// Создаём конструктор
// В Java тривиальный конструктор необязателен,
// однако в JVM нужно всё описывать явно
generateEmptyConstructor(cv);
// Создаём метод evaluate
generateWorkerMethod(cv, expr);
// Заканчиваем создание класса и генерируем байт-код
cv.visitEnd();
return cw.toByteArray();
}
}
Поясню пару моментов.
Во-первых, мы передаём некие параметры в конструктор ClassWriter. Вот зачем это нужно. Дело в том, что в байт-коде методов обязательно указывать размер стека метода и количество слотов под локальные переменные. Так же с некоторых пор необходимо стало добавлять информацию о фреймах — типах переменных и значений на стеке в некоторых точках байт-кода, эта информация позволяет ускорить JIT-компиляцию (в давние времена фреймы были опциональными). Суровые компиляторщики скорее всего всю эту информацию вычислят самостоятельно, но и в образовательных целях, и во многих практических задачах проще поручить эту задачу ASM.
Во-вторых, для диагностики удобно добавлять распечатку сгенерированного байт-кода. Для этого мы используем некоторый ClassVisitor. Тут надо немного рассказать про архитектуру ASM. В нём чтение и запись байт-кода производятся ClassVisitor-ами (а так же MethodVisitor, FieldVisitor и т.д.). При чтении класса мы создаём ClassReader и передаём туда ClassVisitor, который получает от ClassReader-а последовательность команд. ClassWriter наследуется от ClassVisitor и для создания класса нужно вызывать всё те же методы, что вызывает ClassReader при чтении. Так можно, например, трансформировать классы, вставив между reader-ом и writer-ом некоторую логику, однако даже если мы генерируем класс из воздуха, можно пользоваться преимуществами такой архитектуры. Например, в составе ASM есть TraceClassVisitor, которые все вызовы выводит в консоль, чем мы и пользуемся, завернув в него наш ClassWriter.
Итак, теперь напишем генератор пустого конструктора:
private void generateEmptyConstructor(ClassVisitor cv) {
// Создаём метод
var mv = cv.visitMethod(
Opcodes.ACC_PUBLIC, // модификаторы
"<init>", // имя метода
Type.getMethodDescriptor(Type.VOID_TYPE),
// дескриптор метода - типы параметров и возвращаемого значения
null, // сигнатура generic метода
// (для нас не актуально)
null // выбрасываемые исключения
);
mv.visitCode();
// Кладём на стек локальную переменную 0
// (всегда соответствует this для не статических методов)
mv.visitVarInsn(Opcodes.ALOAD, 0);
// Вызываем метод Object.<init>, т.е. конструктор
// родительского класса
// (аналог super() в Java - мы же помним, что в байт-коде
// всё прописывается явно)
mv.visitMethodInsn(
Opcodes.INVOKESPECIAL,
Type.getInternalName(Object.class),
// у какого класса вызываем метод -
// да, в байт-коде нужно быть настолько
// скрупулёзным
"<init>",
Type.getMethodDescriptor(Type.VOID_TYPE),
// дескриптор вызываемого метода
false // вызов *не* у интерфейса
);
// Явно пишем return (хотя в Java он и не обязателен)
mv.visitInsn(Opcodes.RETURN);
// Тут прописываем размер стека и количество слотов
// под локальные переменные, про которые упоминалось
// выше. Мы попросили ASM вычислять их автоматически,
// но вызвать visitMaxs мы обязаны, передав им 0
mv.visitMaxs(0, 0);
mv.visitEnd();
}
Обратите внимание, что конструктор в JVM называется не так же как класс (как это сделано в Java), а имеет специальное имя <init>. Для методов необходимо указывать дескриптор — тип возвращаемого значения и аргументов. JVM определяет специальный синтаксис дескрипторов, в и нашем случае дескриптор имеет вид ()V. Однако, можно попросить ASM сгенерировать дескриптор за нас.
JVM — это стековая машина. Любая операция берёт некоторое количество значений со стека, производит над ними действие и кладёт результат на стек. Например, арифметические команды IADD, ISUB и прочие, снимают с вершины стека два значения и кладут результат операции на вершину стека. В данном случае мы вызываем не статический метод и необходимо в качестве аргумента инструкции INVOKESPECIAL указать получатель (receiver) метода, т.е. то, что стоит слева от точки (хотя в случае c super() синтаксис с точкой не предусмотрен).
Кстати, об INVOKESPECIAL. Есть три инструкции для вызова метода: INVOKESPECIAL, INVOKEVIRTUAL и INVOKEINTERFACE. INVOKESPECIAL — это вызов некоторого метода с заранее известной реализацией, т.е. которую не нужно искать на рантайме. В противовес INVOKEVIRTUAL, когда необходимо нужный метод искать в виртуальной таблице. Такое бывает в следующих случаях: вызов конструктора, вызов super-метода, вызов приватного метода.
Наконец, напишем генератор метода evaluate:
private void generateWorkerMethod(ClassVisitor cv, String expr) {
var mv = cv.visitMethod(
Opcodes.ACC_PUBLIC,
"evaluate",
Type.getMethodDescriptor(Type.DOUBLE_TYPE,
Type.getType(Function.class)),
null, null
);
mv.visitCode();
var generator = new CodeGenerator(mv);
var lexer = new Lexer(expr);
var parser = new Parser(lexer, generator);
parser.parse();
mv.visitInsn(Opcodes.DRETURN);
mv.visitMaxs(0, 0);
mv.visitEnd();
}
всю основную работу делает класс CodeGenerator, которым управляет Parser. В конце своей работы CodeGenerator оставляет одно значение на стеке — результат вычисления последнего выражения. Его и возвращает инструкция DRETURN.
Пишем генератор байт-кода выражений
Парсер отдаёт результат во внешний мир через следующий интерфейс:
public interface ParserConsumer {
void number(double value);
void identifier(String id);
void assignment(String id);
void add();
void subtract();
void multiply();
void divide();
void negate();
void statement();
}
Для выражений парсер вначале уведомляет о парсинге операндов, а затем — о самой операции. Например, для выражения 2 + 3 последовательность будет такой:
number(2)number(3)add()
Наш генератор реализует этот интерфейс:
public class CodeGenerator implements ParserConsumer {
private final MethodVisitor mv;
public CodeGenerator(MethodVisitor mv) {
this.mv = mv;
}
}
Генерация кода для числа выглядит так:
@Override
public void number(double value) {
mv.visitLdcInsn(value);
}
Имя инструкции LDC расшифровывается как "load constant". Думаю, тут всё понятно. Не менее тривиальной выглядит генерация операций:
@Override
public void add() {
mv.visitInsn(Opcodes.DADD);
}
@Override
public void subtract() {
mv.visitInsn(Opcodes.DSUB);
}
@Override
public void multiply() {
mv.visitInsn(Opcodes.DMUL);
}
@Override
public void divide() {
mv.visitInsn(Opcodes.DDIV);
}
@Override
public void negate() {
mv.visitInsn(Opcodes.DNEG);
}
Наконец, ещё одной тривиальной операцией является statement, отделяющее выражения друг от друга:
@Override
public void statement() {
mv.visitInsn(Opcodes.POP2);
}
Она снимает выражение со стека. Смысл в этом вот какой: каждое выражение оставляет на стеке одно значение — результат вычисления выражения. Однако, функция возвращает только значение последнего выражения. Остальные будут скорее всего присваиваниями, их значение можно проигнорировать. Почему же POP2? Дело в том, что в JVM значения типа long и double занимают по два "слота" в стеке и в локальных переменных.
Теперь возьмёмся за переменные. Генератор присвоений реализуем следующим образом:
private final Map<String, Integer> variables = new HashMap<>();
private int lastVariableIndex = 2;
@Override
public void assignment(String id) {
var index = variables.computeIfAbsent(id, k -> introduceVariable());
// Пишем значение со стека в локальную переменную
mv.visitVarInsn(Opcodes.DSTORE, index);
// Читаем значение локальной переменной в стек
mv.visitVarInsn(Opcodes.DLOAD, index);
}
private int introduceVariable() {
var result = lastVariableIndex;
lastVariableIndex += 2;
return result;
}
Т.е. выделяем по два слота в локальных переменных для каждой новой переменной и пишем в локальную переменную значение со стека, а затем снова кладём только что сохранённое значение на стек — это необходимо для того, чтобы воспроизвести семантику присвоения в C/C++, т.е. оно тоже является выражением, результатом которого является значение, присвоенное переменной.
Наконец, сгенерируем чтение переменной:
@Override
public void identifier(String id) {
var index = variables.computeIfAbsent(id, k -> {
var newIndex = introduceVariable();
// Если переменная ещё не упоминалась, пытаемся
// прочитать её из inputs
getAndCacheVariable(newIndex, k);
return newIndex;
});
mv.visitVarInsn(Opcodes.DLOAD, index);
}
private void getAndCacheVariable(int index, String id) {
// переменная с индексом 1 - это параметр inputs
mv.visitVarInsn(Opcodes.ALOAD, 1);
mv.visitLdcInsn(id);
mv.visitMethodInsn(
Opcodes.INVOKEINTERFACE,
// не забываем явно прописать тип receiver-а - Function
Type.getInternalName(Function.class),
"apply",
// erasure в действии. После компиляции от generics
// не остаётся и следа. Теперь любая Function<T,R>
// "превращается" в Function<Object,Object>
Type.getMethodDescriptor(Type.getType(Object.class),
Type.getType(Object.class)),
true
);
// Если результат null - кидаем исключение
var continueLabel = new Label();
// дублируем значение на стеке, т.к. вначале первую копию
// поглощает IFNONNULL, а вторую - логика ниже
mv.visitInsn(Opcodes.DUP);
mv.visitJumpInsn(Opcodes.IFNONNULL, continueLabel);
reportUndefinedVariable(id);
mv.visitLabel(continueLabel);
// erasure в действии - тип у нас стёрся,
// поэтому нужно вставить явный cast к DOUBLE
mv.visitTypeInsn(Opcodes.CHECKCAST, Type.getInternalName(Double.class));
// так же с присущей JVM скрупулёзностью делаем явный unboxing
mv.visitMethodInsn(
Opcodes.INVOKEVIRTUAL,
Type.getInternalName(Double.class),
"doubleValue",
Type.getMethodDescriptor(Type.DOUBLE_TYPE),
false
);
mv.visitVarInsn(Opcodes.DSTORE, index);
}
логика сгенерированного байт-кода может быть выражена следующим псевдокодом:
Object value = inputs.apply("varName");
if (value == null) {
throw new ExecutionException("Undefined variable varName");
}
double varName = ((Double) value).doubleValue();
Наконец, напишем выброс исключения:
private void reportUndefinedVariable(String id) {
// В JVM отсутствует операция вызова конструктора.
// Вместо этого вначале надо создать пустой объект,
// А потом вызвать для него метод <init>
mv.visitTypeInsn(Opcodes.NEW,
Type.getInternalName(ExecutionException.class));
// Первый раз наше исключение передаётся в <init>
// Второй раз - в инструкцию ATHROW
mv.visitInsn(Opcodes.DUP);
mv.visitLdcInsn("Undefined variable " + id);
mv.visitMethodInsn(
Opcodes.INVOKESPECIAL,
Type.getInternalName(ExecutionException.class),
"<init>",
Type.getMethodDescriptor(Type.VOID_TYPE,
Type.getType(String.class)),
false
);
mv.visitInsn(Opcodes.ATHROW);
}
Создаём класс в рантайме
В принципе, наш код уже умеет генерировать байт-код, однако что с ним делать? Можно сохранить его на диск в файл с расширением class и линковать к коду. Однако, полезность такой утилиты невысока. Интереснее запустить его тут же, используя старый добрый reflection:
public class Compiler {
private final ClassLoader classLoader;
public Compiler(ClassLoader classLoader) {
this.classLoader = classLoader;
}
public Expression compile(String expr) {
var bytecode = new ClassGenerator().generate(expr);
var loader = new ProvidedBytecodeClassLoader(classLoader, bytecode);
Class<?> cls;
try {
cls = Class.forName(ClassGenerator.CLASS_NAME, false, loader);
} catch (ClassNotFoundException e) {
throw new RuntimeException(e);
}
try {
return (Expression) cls.getConstructor().newInstance();
} catch (InstantiationException
| IllegalAccessException
| NoSuchMethodException
| InvocationTargetException e) {
throw new RuntimeException(e);
}
}
}
Секретный ингредиент здесь:
public class ProvidedBytecodeClassLoader extends ClassLoader {
private final byte[] bytecode;
public ProvidedBytecodeClassLoader(ClassLoader parent, byte[] bytecode) {
super(parent);
this.bytecode = bytecode;
}
@Override
protected Class<?> findClass(String name) throws ClassNotFoundException {
if (!name.equals(ClassGenerator.CLASS_NAME)) {
return super.findClass(name);
}
return defineClass(ClassGenerator.CLASS_NAME, bytecode, 0, bytecode.length);
}
}
Пусть вас не смущает то, что класс всегда создаётся по одному имени. В JVM имя класса не обязано быть уникальным, уникальной должна быть пара (имя класса, ClassLoader). Каждое новое выражение будет загружено через новый ClassLoader, поэтому никаких проблем у нас не возникнет.
Пишем парсер
Здесь нет ничего особенного с точки зрения именно нашей задачи. Руководств по тому, как это правильно делать, достаточно много. Поэтому я приведу код с минимальным количеством комментариев. В качестве домашнего задания можете пропустить этот раздел и написать парсер самостоятельно.
Итак, обычно парсер разделяют на лексер и собственно парсер. Лексер разбивает поток символов на лексемы. Определим для начала список лексем нашего языка:
public enum Token {
NUMBER,
PLUS,
MINUS,
STAR,
SLASH,
LEFT_BRACE,
RIGHT_BRACE,
SEMICOLON,
ASSIGNMENT,
IDENTIFIER,
EOF
}
и напишем сам лексер:
public class Lexer {
private final CharSequence inputString;
private int position;
private Token token;
private int tokenPosition;
private double number;
private String identifier;
public Lexer(CharSequence inputString) {
this.inputString = inputString;
}
public void next() {
if (token == Token.EOF) {
return;
}
skipWhitespace();
identifier = null;
number = 0;
tokenPosition = position;
if (position == inputString.length()) {
token = Token.EOF;
return;
}
var c = inputString.charAt(position);
switch (c) {
case '+':
simpleToken(Token.PLUS);
break;
case '-':
simpleToken(Token.MINUS);
break;
case '*':
simpleToken(Token.STAR);
break;
case '/':
simpleToken(Token.SLASH);
break;
case '(':
simpleToken(Token.LEFT_BRACE);
break;
case ')':
simpleToken(Token.RIGHT_BRACE);
break;
case '=':
simpleToken(Token.ASSIGNMENT);
break;
case ';':
simpleToken(Token.SEMICOLON);
break;
default:
if (isIdentifierStart(c)) {
parseIdentifier();
} else if (isDigit(c)) {
parseNumber();
} else {
error("Unexpected character");
}
break;
}
}
private void simpleToken(Token token) {
this.token = token;
++position;
}
private void skipWhitespace() {
while (position < inputString.length()
&& Character.isWhitespace(inputString.charAt(position))) {
++position;
}
}
private void parseIdentifier() {
token = Token.IDENTIFIER;
tokenPosition = position;
while (position < inputString.length()
&& isIdentifierPart(inputString.charAt(position))) {
++position;
}
identifier = inputString.subSequence(tokenPosition, position).toString();
}
private void parseNumber() {
token = Token.NUMBER;
while (position < inputString.length()
&& isDigit(inputString.charAt(position))) {
++position;
}
if (position < inputString.length()
&& inputString.charAt(position) == '.') {
++position;
if (position >= inputString.length()
|| !isDigit(inputString.charAt(position))) {
error("Invalid number literal");
}
while (position < inputString.length()
&& isDigit(inputString.charAt(position))) {
++position;
}
}
try {
number = Double.parseDouble(inputString.subSequence(
tokenPosition, position).toString());
} catch (NumberFormatException e) {
error("Invalid number literal");
}
}
private static boolean isIdentifierStart(char c) {
switch (c) {
case '$':
case '_':
return true;
default:
return c >= 'a' && c <= 'z' || c >= 'A' && c <= 'Z';
}
}
private static boolean isIdentifierPart(char c) {
return isIdentifierStart(c) || isDigit(c);
}
private static boolean isDigit(char c) {
return c >= '0' && c <= '9';
}
private void error(String error) {
throw new ParseException(error, position);
}
public int getTokenPosition() {
return tokenPosition;
}
public Token getToken() {
return token;
}
public double getNumber() {
return number;
}
public String getIdentifier() {
return identifier;
}
}
Предполагается, что у лексера последовательно вызывают next, он читает очередную лексему, и далее можно через публичные методы получать её свойства.
Наконец, парсер:
public class Parser {
private final Lexer lexer;
private final ParserConsumer consumer;
public Parser(Lexer lexer, ParserConsumer consumer) {
this.lexer = lexer;
this.consumer = consumer;
}
public void parse() {
lexer.next();
parseSum();
while (lexer.getToken() == Token.SEMICOLON) {
skipSemicolons();
if (lexer.getToken() == Token.EOF) {
break;
}
consumer.statement();
parseSum();
}
if (lexer.getToken() != Token.EOF) {
error("End of input expected");
}
}
private void skipSemicolons() {
while (lexer.getToken() == Token.SEMICOLON) {
lexer.next();
}
}
private void parseSum() {
parseProd();
while (lexer.getToken() == Token.PLUS || lexer.getToken() == Token.MINUS) {
var token = lexer.getToken();
lexer.next();
parseProd();
if (token == Token.PLUS) {
consumer.add();
} else {
consumer.subtract();
}
}
}
private void parseProd() {
parsePrime();
while (lexer.getToken() == Token.STAR || lexer.getToken() == Token.SLASH) {
var token = lexer.getToken();
lexer.next();
parsePrime();
if (token == Token.STAR) {
consumer.multiply();
} else {
consumer.divide();
}
}
}
private void parsePrime() {
switch (lexer.getToken()) {
case NUMBER:
consumer.number(lexer.getNumber());
lexer.next();
break;
case IDENTIFIER:
parseIdentifierOrAssignment();
break;
case MINUS:
lexer.next();
parsePrime();
consumer.negate();
break;
case LEFT_BRACE:
lexer.next();
parseParenthesized();
break;
default:
error("Unexpected token");
break;
}
}
private void parseIdentifierOrAssignment() {
var id = lexer.getIdentifier();
lexer.next();
if (lexer.getToken() == Token.ASSIGNMENT) {
lexer.next();
parseSum();
consumer.assignment(id);
} else {
consumer.identifier(id);
}
}
private void parseParenthesized() {
parseSum();
if (lexer.getToken() != Token.RIGHT_BRACE) {
error("Closing brace expected");
}
lexer.next();
}
private void error(String error) {
throw new ParseException(error, lexer.getTokenPosition());
}
}
Пример
Проверим получившийся калькулятор:
var compiler = new Compiler(ClassLoader.getSystemClassLoader());
var expr = compiler.compile("pi = 3.14159; pi * r * r");
var inputs = new HashMap<String, Double>();
inputs.put("r", 2.0);
System.out.println(expr.evaluate(inputs::get));
inputs.put("r", 5.0);
System.out.println(expr.evaluate(inputs::get));
вывод:
12.56636 78.53975
Однако, гораздо интереснее посмотреть сгенерированный байт-код. Запускаем с системным свойством konsoletyper.exprbc.log=true:
; pi = 3.14159 LDC 3.14159 DSTORE 2 DLOAD 2 POP2 ; первое вычисление r DLOAD 2 ALOAD 1 LDC "r" INVOKEINTERFACE java/util/function/Function.apply (Ljava/lang/Object;)Ljava/lang/Object; (itf) DUP IFNONNULL L0 NEW konsoletyper/exprbc/ExecutionException DUP LDC "Undefined variable r" INVOKESPECIAL konsoletyper/exprbc/ExecutionException.<init> (Ljava/lang/String;)V ATHROW L0 CHECKCAST java/lang/Double INVOKEVIRTUAL java/lang/Double.doubleValue ()D DSTORE 4 DLOAD 4 ; pi * r DMUL ; второе вычисление r ; теперь значение закэшировано в локальной переменной DLOAD 4 ; pi * r * r DMUL DRETURN
Зачем это всё?
Казалось бы, я должен был поместить статью в хаб "ненормальное программирование". Однако, у генерации байт-кода есть свои применения. Во-первых, это производительность. Хотя редко, но бывает, что какое-то узкое место можно оптимизировать только генерацией байт-кода. Во-вторых, это навешивание всякой дополнительной функциональности на имеющиеся классы (например, сериализация, RPC). И хотя всё то же самое можно сделать через reflection, у reflection есть один недостаток: он плохо работает с AOT-компиляторами, которым в какой-то мере является, например, Android SDK, а точнее его часть под названием r8. Сюда же относится Graal Native Image, который можно использовать для запуска Java-приложений на iOS. Альтернативой генерации байт-кода здесь являются annotation processor. Однако, у них есть ряд недостатков:
- Они плохо работают на стыке Java и Kotlin.
- Они плохо дружат с инкрементальной компиляцией. Точнее, они с ней дружат, но порой внезапно система сборки хочет перекомпилировать слишком много всего. Сгенерировать байт-код обычно намного быстрее, чем спарсить и порезолвить часть исходников модуля.
- Иногда при работе с generics в случае с исходниками приходится очень сильно заморачиваться, чтобы правильно вывести типовые аргументы. В байт-коде все generics стёрты и проблемы просто нет.
Наконец, байт-код иногда не генерируют с нуля, а модифицируют существующий. Такое уж точно нельзя заменить никакими reflection или annotation processor.
Есть, правда, пара трудностей:
- Отлаживать всё это достаточно тяжело — некуда поставить брейкпоинт. Теоретически можно через ASM вписывать в байт-код информацию для отладчика, можно параллельно генерировать какой-нибудь псевдокод. Вот только мне не известны способы заставить IDE всё это понимать.
- Порой приходится иметь дело с багами ASM. Когда мы генерируем заведомо валидный байт-код, всё работает как часы. Однако, порой при генерации невалидного байт-кода ASM просто крэшится вместо того, чтобы напечатать понятное сообщение об ошибке.