Comments 4
Лайк
Если GUI на JavaFX почему не использовали компиляцию в натив через GraalVM? плагин gluonfx (есть mvn есть gradle версии) дают вроде элементарный способ: mvn gluonfx:build и на выходе получается полностью самодостаточный нативный исполняемый файл.
Вроде даже позволяет мобильные apk и что-то там для яблок собирать. Но это я не пробовал. А вот для win и linux собирает очень шустрые образы. Ресурсов потребляют заметно меньше чем то-же самое запущенное в виде jar-а.
Самое главное, что jpackage - это инструмент из "коробки" JDK и мы умеем с ним работать. Нам показалось, что создание нативного образа с помощью GraalVM требует значительных усилий по настройке. Может понадобиться явно указывать, какие классы и ресурсы должны быть включены в образ, что может быть трудоемким процессом.
Так же у нас использовались библиотеки, которые пока не полностью поддерживаются в GraalVM.
А образ, который мы в итоге собрали через плагин GluonFX, получился несколько больше по размеру чем у jpackage.
Спасибо, затронули больную тему: сама собираю приложение (и микрофреймворк для него подобный брошенному TornadoFX) для javafx. И всё бы хорошо, но плагин javafx для gradle сломали в версии 1 и потому приходится пользоваться 0.14 (нельзя выставить зависимости api вместо implementation - для монолитного приложения это ничего, но для фреймворка это важно)
А сам jlink плагин badass работает на ура: собирает и запускаемое приложение и инсталлятор, как положено, со всеми зависимостями, параметрами командной строки и прочим.
У меня не было проблем и нареканий.
JPackage в gradle для Java17