Comments 13
Спасибо! С удовольствием прочитал.
Есть ещё один юзкейс для graal native image: компиляция приложений под iOS. Иногда в этом есть смысл, если хочется на Java/Kotlin ваять кроссплатформенно, но нативный look&feel вообще не нужен (например, игры).
Что касается неудобств с reflection, то тут есть одно решение: не использовать. Вы не поверите, на что способны annotation processor в умелых руках, дополненных compile time инструментацией байт-кода. Хотя полагаю, что, для spring boot это может быть невозможно.
Спасибо за комментарий!
К сожалению, с IOS не приходилось работать, но интересно звучит. Читал, что есть нативные возможности самого котлина для кроссплатформенной сборки под Android и IOS.
Да, такие возможности есть, но это работает только в случае, если приложение написано целиком на Kotlin. Если же это Kotlin + Java, то спасает только native image или другие подобные AOT-компиляторы. Честно, я не в курсе, что сейчас творится на этом рынке, когда-то ещё были MOE, RoboVM и Avian, здравствуют ли они поныне - я не проверял.
Я часто вижу статьи про
нативное приложение стартует почти в 14 раз быстрее обычного *.jar
но почему-то никто не пишет, насколько медленнее такое приложение работает :)
По моим тестам, приложение на micronaut, с методом, который разжимает-сжимает json-ы через jackson, держит примерно в два раза меньше RPS на четырёх ядрах, чем нетюненая JVM с G1GC.
Я, к сожалению, про RPS не могу сказать, т.к. профиль нагрузки это десктопное приложение с не большими вычислениями (сейчас под активной нагрузкой CPU от Java приложения не выходит за 70% от ядра) и я не измерял, но проверить под нагрузкой это хороший поинт. Будет время - проверю.
Наблюдал совершенно обратную ситуацию с RPS. Только не на синтетическом кейсе, а готовом приложении. Натив это не только старт, но и меньше cpu/mem. Точных цифр не помню, но условно 15-30% там было. Вместо micronaut был quarkus
в теории должно быть лучше
Это известный факт, что throughput у нативных приложений хуже. И происходит это из-за того что jit оптимизирует код гораздо лучше чем aot компилятор. Да холодный старт гораздо быстрее, но после прогрева jvm будет скорее выигрывать в пропускной способности у нативного приложения.
Electron, React... Выглядит как-то чересчур. Неужели нет способа попроще и если надо сделать банальное десктоп-приложение, без всяких красивостей?
Я смотрю на Dart/Flutter, вроде позволяет собрать десктоп и есть встроенные библы для создания UI. Но это другой язык, хоть и похож на Java. И некоторый бардак с библиотеками.
Есть ли что-то для экосистемы JVM? Ну, кроме JavaFX? Что позволило бы просто собрать "экзешник"? Я бы даже поступился идеей полной кроссплатформенности в том смысле что если придётся "фронт" пилить под каждую ОС, то ладно, далеко не всегда требуется приложение под все платформы.
Как раз цель была в красивости и удобстве (учитывая что за это платят деньги). Второе ограничение - это некоторые специальные библиотеки для проекта, доступные для JAVA.
Банальное десктопное приложение можно писать на чем угодно - согласен, но обычно это не production-ready система, которую захотят покупать пользователи.
Да и мне как JAVA разработчику гораздо удобней использовать язык который я хорошо знаю, а REACT я тоже немного знал и с ним все было просто. Опять же, почему REACT - я купил готовый HTML + REACT шаблон и получил красивый дизайн и набор всех компонентов из коробки, которые просто блоками копирую и вставляю какие нужны. Сэкономил месяцы времени только на UI и дизайне.
Поэтому тут каждый выбирает инструменты под задачи. Достойных альтернатив нативной компиляции я пока не встречал.
Создаем нативное Kotlin приложение на Spring Boot Native, Gradle и GraalVM без докера под MacOS и Windows