Комментарии 15
Как эксперимент, это наверное интересно, но пока не понимаю где можно применить полученные бонусы (быстрый старт и запуск без установленной java). В той области, где традиционно сильна Java, это все не настолько критично, особенно наличие установленной java. А вот как такое приложение будет работать под нагрузкой, как его мониторить и т.д. это вот куда важнее.
Я вижу себе это так: расширение области применения языка Java. Действительно, там где сейчас Java сильна, особо нет смысла делать ее бинарной. А вот чтобы раздвинуть границы этой области — возможность создавать бинарники — сильный аргумент. Вот есть Golang, он так умеет с самого начала, и на нем написаны замечательные программы: Consul, Docker в которых отсутствие требования установки какой то виртуальной машины скорее плюс чем минус.
десктопные приложения а-ля ide, admin, etc.
по поводу мониторинга — думаю jmx будет также доступен на портах и все остальное по аналогии… при имплементации пуш-подхода вообще ничего не поменяется.
быстрое время старта будет полезно в serverless…
ps главное чтобы работало стабильно и не отставала от актуальной версии
по поводу мониторинга — думаю jmx будет также доступен на портах и все остальное по аналогии… при имплементации пуш-подхода вообще ничего не поменяется.
быстрое время старта будет полезно в serverless…
ps главное чтобы работало стабильно и не отставала от актуальной версии
десктопные приложения а-ля ide, admin, etc.
ide, написанные на java можно пересчитать по пальцам (возможно даже одной руки), при этом основная масса пользователей используют их для разработки… на Java, т.е. все равно ставить придется.
Ну и к тому же, это все профессиональные инструменты (как и админки), а для такого нет большой проблемы поставить jvm.
Существование такой возможности, как standalone приложения, открывает некоторые горизонты, куда ява особо и не ходила: инструменты такого класса как докер, утилиты с мгновенным запуском, то есть туда где обычно писались программы на C/C++, или на Go. Можно конечно выучить эти языки, а можно и остаться на знакомом. Ведь не заставишь же пользователя небольшой утилиты устанавливать ради нее какую то яву машину, выяснять совместимость ява машин разных версий и запускаемой утилиты. Да, есть вариант распространять яву машину с утилитой, это уже не простой бинарник будет, а набор файлов, какой то скрипт запуска и JIT все равно потребуется, и при запуске маленькой программы все равно есть ощутимые задержки, пусть даже потом она отработает мгновенно.
Да, тут согласен, но это как раз слабая на данный момент сторона Java. Вопрос в том, выстрелит это или нет. Тут есть несколько потенциальных трудностей: удовлетворит ли «пользователя небольшой утилиты» размер этой утилиты, при этом надо понимать, что каждая такая утилита будет тащить с собой свой «домик» примерно как сейчас это делают приложения на electron; удовлетворит ли разработчиков скорость сборки бинарника (например, для тестирования) и насколько удобными будут инструменты генерации под все платформы и т.д.
Вот с «домиком» тут интересная штука. Разработчики SubstrateVM утверждают, что ничего лишнего туда не попадает, следствие этого — необходимость указывать случаи рефлекшена и включаемые ресурсы. То есть сборщик просматривает весь граф выполнения (из-за этого долгая сборка) и включает туда только тот код который может выполниться из программы, ничего лишнего. Сборка программы которая печатает «привет мир» занимает 30 секунд и весит 2.5 МБ. То есть какого-либо обязательного «домика» в десятки мегабайтов, как электрон, она не таскает. Да, программа с подключением двух фреймворков и JDBC драйвера уже весит 70МБ и сборка занимает пять минут, это и на маленькую утилиту она уже не тянет.
ide — это не только Eclipse, NetBeans или IntelliJ IDEA. Это еще например DBeaver и подобные инструменты. Зачем дата- моделеру/админу ставить жаву?!
Еще пример — админка одно из производителей точек доступа написана на джава. Точками доступа пользуются очень разные люди. Они могут даже не знать, что жава не только кофе…
Еще пример — админка одно из производителей точек доступа написана на джава. Точками доступа пользуются очень разные люди. Они могут даже не знать, что жава не только кофе…
это не только Eclipse, NetBeans или IntelliJ IDEA. Это еще например DBeaver и подобные инструменты
Да, поэтому я и писал про основную массу пользователей. Все таки Eclipse чаще всего используют для Java, а не кастомизуют (DBeaver, 1C и т.д.)
Зачем дата- моделеру/админу ставить жаву?!
Разумеется, незачем.
Я не против таких приложений в принципе, просто рассматриваю насколько эффект стоит затрат.
Есть ли разница в производительности и потребления памяти/процессора нативного приложения и обычного jar-файла?
Какую-то серьезную проверку я пока не делал. Скорее всего это будет тема следующей статьи. По ощущениям, памяти в бинарнике тратится меньше, хотя бы за счет того что метаданные классов по умолчанию не попадают в бинарник и класс-спейс не занят ими. По процессору думаю будет почти также — если конечно «прогреть» jar, чтобы время на JIT не тратилось. Хотя по пресс-релизам Graal проводит более серьезные оптимизации чем традиционный JIT.
В native-image заявляют скорость ниже, чем у прогретой jvm, но значительно выше, чем у непрогретой.
Т.е. жто всё-таки не для долгоживущих приложений, а для утилит коммандной строки и т.п.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Java Native Image: проверка возможности использования