Насколько я знаю, сейчас таких планов нет (а думали ли об этом на старте проекта - сказать не могу).
Тут есть два важных момента. Во-первых, издержки на рефлексию у нас случаются ровно один раз - на этапе прогрева, когда мы впервые встречаем класс и генерируем для него сериализатор. На «горячую» сериализацию самих объектов это уже никак не влияет, там работает чистый сгенерированный код. Во-вторых, в большинстве наших сценариев статической генерации просто недостаточно: нам критически важна прямая и обратная совместимость версий объектов (эволюция схемы), и здесь гибче всего справляется именно динамика.
С другой стороны, под капотом уже есть всё, чтобы прикрутить AOT-режим. При желании это делается минимальными обвязками: на этапе сборки дернуть генерацию сериализаторов для нужных классов, сдампить их байт-код на диск (про опцию дампа я писал в заключении), а в рантайме просто зарегистрировать готовые классы во фреймворке.
С Apache Fory не сравнивали. В целом было бы интересно поэкспериментировать и с ним, учитывая, что у наших решений много концептуальных пересечений в плане архитектуры.
Спасибо за вопрос! Основным препятствием для использования сериализации one-nio с GraalVM в режиме Native image исторически была динамическая генерация байт-кода (сериализаторов). Последняя версия GraalVM начинает снимать важные ограничения (насколько я понимаю, это всё ещё в стадии preview), добавляя динамическую загрузку классов и их динамическую компиляцию (проект Crema), и это потенциально разблокирует новые сценарии использования библиотеки. Тут много интересного, но на данный момент мы туда пока плотно не смотрели.
Насколько я знаю, сейчас таких планов нет (а думали ли об этом на старте проекта - сказать не могу).
Тут есть два важных момента. Во-первых, издержки на рефлексию у нас случаются ровно один раз - на этапе прогрева, когда мы впервые встречаем класс и генерируем для него сериализатор. На «горячую» сериализацию самих объектов это уже никак не влияет, там работает чистый сгенерированный код. Во-вторых, в большинстве наших сценариев статической генерации просто недостаточно: нам критически важна прямая и обратная совместимость версий объектов (эволюция схемы), и здесь гибче всего справляется именно динамика.
С другой стороны, под капотом уже есть всё, чтобы прикрутить AOT-режим. При желании это делается минимальными обвязками: на этапе сборки дернуть генерацию сериализаторов для нужных классов, сдампить их байт-код на диск (про опцию дампа я писал в заключении), а в рантайме просто зарегистрировать готовые классы во фреймворке.
С Apache Fory не сравнивали. В целом было бы интересно поэкспериментировать и с ним, учитывая, что у наших решений много концептуальных пересечений в плане архитектуры.
Спасибо за вопрос! Основным препятствием для использования сериализации one-nio с GraalVM в режиме Native image исторически была динамическая генерация байт-кода (сериализаторов). Последняя версия GraalVM начинает снимать важные ограничения (насколько я понимаю, это всё ещё в стадии preview), добавляя динамическую загрузку классов и их динамическую компиляцию (проект Crema), и это потенциально разблокирует новые сценарии использования библиотеки. Тут много интересного, но на данный момент мы туда пока плотно не смотрели.