Comments 3
У меня на работе мы нашли применение native image: компиляция приложения в iOS - там нельзя JIT ни под каким соусом. Получается, можно из одного набора исходников (с небольшой платформо-специфической частью) собирать приложения для Android, iOS и для веба (привет, компиляторы Java в JS).
У нас в проде на базе Quarkus микросервис, переписанный с Spring Boot и скомпилированный в нативный образ, уже наверное с год работает, без особых проблем. В нем используются библиотеки типа MariaDB, Hashicorp Vault, Spring Cloud Config Client, и т.д.
Сейчас на подходе пара-тройка микросервисов на Spring Boot 3.0 с AOT. В них как либы для мускла, так и для rabbitmq, vault, spring cloud и прочие необходимые плюшки. Не без скрипа, но в QA уже что-то вполне рабочее.
По замерам метрик нативные образы выглядят менее прожорливыми до ресурсов, особенно на старте. По быстродействию, однако, примерно одинаковы с JIT.
Так что не всё так уж и плохо, а то статья уж, на мой взгляд, шибко мрачно заканчивается :)
А как приложение работает с памятью? Есть точно такое-же разделение на хип/не хип? Где задается это ограничение, при запуске исполняемого файла флагом?
Разбираемся с GraalVM, AOT и JIT