Комментарии 19
Во всех нейтив сборках половина фичей Джавы не работает, а код исполняется медленнее. Не думаю что в этот раз что-то изменилось.
компилятор должен знать все пути исполнения при сборке. Поэтому рефлексия, JNI, динамические прокси и подгрузка классов на лету без явного описания в конфигах падают. Многие старые библиотеки не заводятся в принципе.
На практике в Spring Boot 3 и Quarkus это уже решено автоматической генерацией метаданных при сборке.
В Axiom NIK по умолчанию трудится Serial GC, и он делает это настолько филигранно, что система мониторинга просто не фиксирует пауз
может просто не умеет фиксировать паузы?
за старт в 1.4 с мы платим 13 минутами сборки
Также, очевидно, упала скорость по сравнению с jit после прогрева.
GraalVM для микросервисов. Для монолита jit
в 2000 году я запускал java на машине с процессором 80386 5Мб RAM под Win95. помню JRE что то около 1.8Мб в архиве был
И запускался дольше чем хостовая ОС.
Причем такое поведение наблюдалось еще много лет.
Только я под OS/2 Warp крутил. И позже под Netware 6
Все так. Но проблема сейчас в программистах после курсов и применении AI-генерации кода. Мой старый комп при прохождении вышеупомянутых курсов,к сожалению,сломался. Было обидно. Поэтому поднял тему оптимизаций Java-рантайма. Компьютеры нынче дорогие
"Мы сделали кроссплатформеное решение, которое надо компилировать под каждую платформу отдельно"
Почему то нигде нет графиков сравнения утилизации cpu. У меня под нагрузкой сервис 10k rps. Реквесты 30 ядер лимиты 60. Достаточно много вычислений под капотом не просто crud. Почему такой важный параметр обошли стороной?
У вас пункты дублируются начиная с 8го.
Я не буду отвечать в комментариях
И за это тоже минус.
Опять продавцы из аксиом впаривают GraalVm как якобы "свое новейшее изобретение", которым оно никогда не являлось, за большие деньги между прочим
Вот что высокие цены на оперативку творят!
9.Парадок нагрузки
Хабр утонул в низкокачественных нейрогаллюцинациях, которые авторы даже не читают перед публикацией.
В случае с нативной сборкой цикл доставки сильно увеличивается(только не нужно мне рассказывать про то, что можно разные степени оптимизации нативного образа указывать).
Нативные сборки безусловно имеют свое место и нишу, но точно ни как мэйнстрим на сеголняшний день.
Для большей части приложений потребление памяти НЕ является проблемой.
На мой взгляд, революцией в Java станет внедрение Project Valhalla когда(если) его наконец доделают и внедрят.
Для большей части приложений потребление памяти НЕ является проблемой.
Уже давно ни одного Джава - приложения на компе. Нет Джавы - нет проблем с потреблением памяти.
А вообще конечно брейкинг ньюс - скомпилированные в нейтив приложения быстрее и меньше жрут. Но джаве даже АОТ не поможет - слишком много завязано на хип.

Java на диете: 45 МБ RAM и старт за 1.4 с. Смертный приговор классическим JVM?