company_banner

Графика для JVM

Автор оригинала: Nikita Prokopov
  • Перевод


Допустим, я хочу создавать качественные десктопные приложения. Я также хочу сделать это на JVM. Не надейтесь — мы еще не достигли цели. Но у меня есть план.

Почему именно JVM?


Это производительность на достаточно высоком уровне, но не заставляет вас слишком много задумываться о каждом выделение памяти. Это кроссплатформенно. В нем есть отличные языки — Kotlin, Scala и, конечно же, Clojure. C # тоже подойдет, но в нем нет Clojure.

Разве вы уже не можете создавать десктопные приложения на JVM?


Вы можете. Но традиционно AWT, Swing и JavaFX сопровождались множеством недостатков в качестве и производительности. Они были настолько существенными, что только одной компании удалось создать прилично выглядящее приложение на Swing. Это возможно, но требует огромных усилий.

Разве не все пользовательские интерфейсы Java прокляты?


Нет, не совсем. У AWT, Swing и JavaFX есть свои проблемы, но это исключительно их проблемы. Нет фундаментальной причины, по которой невозможно создать высококачественный пользовательский интерфейс на JVM. Просто это еще не было сделано.

Почему это еще не было сделано?


Я думаю, это связано с терпением. Мы так привыкли к вещам, которые можно собрать за неделю, что никто не думает о годах. А для хорошего пользовательского интерфейса требуются годы работы. Это большое обязательство.

Почему не Electron?


Первая причина — производительность. JS — отличный язык для создания пользовательского интерфейса, но он намного медленнее, чем JVM. Wasm может быть быстрым, но подразумевает C ++ или Rust.

Второй — это модель DOM. Это ужасающая коллекция уловок, которые делают простые вещи сложными, а сложные — невозможными. Я много раз думал: «Если бы я рисовал этот элемент управления/макет напрямую, я бы закончил несколько часов назад».

Это означает, что существует очень низкий предел возможностей веб-приложений с точки зрения производительности и качества. Я считаю, что мы можем и должны добиться большего.

Однако Electron научил нас двум хорошим вещам:

  • Люди жаждут нативных приложений. Никто не хочет работать из браузера.
  • Людей не волнует, что приложения не выглядят нативными для платформы, если они хорошо выглядят.


Десктоп по-прежнему актуален?


Я верю, что это так!

Недавно я смотрел интервью между разработчиком Android и разработчиком iOS. Один спрашивал:

«Кто-нибудь по-прежнему пишет десктопные приложения?»

На что другой ответил:

«Понятия не имею… Может быть?»

Оба они записывали его на десктопе, в десктопном приложении, во время разговора через другое десктопное приложение. Вероятно, для пост-обработки использовалось несколько других десктопных приложений. Ни один из них не был написан волшебными эльфами и не оставлен нам могущественной древней цивилизацией. Десктоп может быть менее модным, но только потому, что здесь труднее продавать бесполезную хрень.

И я был на обеих сторонах. Однажды я жил без десктопа несколько недель. К этому привыкаешь, но это, конечно, не идеал. Сбор и обработка любой информации очень болезненны: сложно выделить текст, сложно выполнить поиск на странице, сложно иметь несколько вкладок, сложно перемещать данные между приложениями. Например, вы добавляете событие в календарь. Вам нужно найти адрес события в почте, где есть ссылка, открывающая браузер. К тому времени, когда вы нашли то, что вам нужно, и вернули в календарь, оно уже выгружается из памяти, и весь контекст теряется. Возможность одновременного открытия нескольких окон — это суперспособность десктопа.

Телефоны отлично подходят для небольших быстрых одноцелевых задач. У них есть свое место, но жизнь намного сложнее, чем телефон. Многим из нас все еще нужен этот велосипед для ума.

Хорошо, что же ты предлагаешь?


Путь к качественному пользовательскому интерфейсу на JVM — долгий. Нам понадобятся:

  • графическая библиотека,
  • библиотека интеграции окна / ОС,
  • набор инструментов пользовательского интерфейса.


Сегодня я рад анонсировать первую часть этого эпического квеста: графическую библиотеку. Она называется Skija и представляет собой просто набор привязок к очень мощной, хорошо известной библиотеке Skia. Та, которую поддерживает Chrome, Android, Flutter и Xamarin.

image

Как и любая другая библиотека JVM, она кроссплатформенная. Она работает в Windows, Linux и macOS. Это так же просто, как добавить файл JAR. Намного проще, чем массировать флаги компилятора C ++ в течение нескольких дней, прежде чем вы сможете что-либо скомпилировать. Skija позаботится об управлении памятью за вас. И привязки создаются вручную, поэтому они всегда имеют смысл и доставляют удовольствие (по крайней мере, насколько позволяет Skia API).

Что с этим делать? В основном рисовать. Линии. Треугольники. Прямоугольники. Но также: кривые, контуры, формы, буквы, тени, градиенты.

image

Думайте об этом как о Canvas API. Но вроде бы действительно продвинутой версии. Она понимает цветовые пространства, современную типографику, макет текста, ускорение графического процессора и тому подобное.

image

О, и это быстро. Действительно быстро. Если этого достаточно для Chrome, вероятно, этого будет достаточно и для вашего приложения.

Что я могу с этим сделать?


Много вещей! Пользовательские библиотеки виджетов пользовательского интерфейса и целые наборы инструментов, графики, диаграммы, визуализации, игры. Например, мы поигрались с реализацией java.awt.Graphics2D и запуском Swing поверх него — похоже, все работает нормально.

Зачем выпускать отдельную графическую библиотеку? Чем это полезно?


Я не большой поклонник объединять все в одном месте. Вы никогда не сможете угадать все детали правильно — кто-то всегда будет недоволен конкретным решением.

Независимые взаимозаменяемые библиотеки более гибкие. Философия Unix.

Что с остальной кусочками паззла?


Обе вещи находятся в разработке в JetBrains.

  • Для интеграции управления окнами и ОС есть Skiko. Она говорит, что это Skia для Kotlin, но она также реализует создание окон, события, пэкэджинг и все остальное. Она даже интегрируется с AWT и Swing.
  • А для инструментария пользовательского интерфейса есть Compose Desktop. Это форк Android Compose, декларативного UI-фреймворка, работающего в десктопной среде.


Но прелесть в том, что это даже не обязательно эти двое!

Не нравится AWT? Принесите свою собственную библиотеку окон.

Kotlin не подходит Вам? Используйте любой другой язык JVM.

Compose плохо справляется с нагрузкой? Молитесь, чтобы кто-нибудь написал альтернативу или написал что-то свое (извините, но хорошего решения пока нет. Это еще только начало).

И, конечно, если вы хотите развернуть свою собственную библиотеку окон или набор инструментов для виджетов — пожалуйста, сделайте это! Мы надеемся, что это произойдет.

В заключение


Skija — это часть более широкой картины. Прогресс пользовательского интерфейса Java был заблокирован некачественной Graphics2D. Но все меняется. Что из этого выйдет? Время покажет.

Пожалуйста, попробуйте Skija и поделитесь с нами своим мнением. Или, может быть, начните ей пользоваться — мы были бы счастливы, если бы вы это сделали! Вот ссылка:

github.com/JetBrains/skija

14 ноября 2020 · Обсуждение на HackerNews



Облачные серверы от Маклауд быстрые и безопасные.

Зарегистрируйтесь по ссылке выше или кликнув на баннер и получите 10% скидку на первый месяц аренды сервера любой конфигурации!

Маклауд
Облачные серверы на базе AMD EPYC

Комментарии 30

  • НЛО прилетело и опубликовало эту надпись здесь
      +4

      Можно чуть подробнее про пресловутые кривые интерфейсы на JavaFX и упомянутое множество проблем с ней?

        +1
        Интерфейс норм, но вот со сборкой в джарник у меня лично проблемы были.
        Или ексепшины, или пустые джарники собирало, или они не могли запуститься, потому что в манифесте что-то не так
        Да, про сайт с инструкцыями я тоже знаю(не вспомню щас адрес, но там расписано как собирать джарники)
        Хз, может это моя личная проблема, но это пример проблем с JavaFX
          0
          По канону, имхо, приложение JavaFX собирается не в JAR, а в установочный файл конкретной платформы. С Java SE 16 вы можете использовать JLink и JPackage для этих целей (JPackage при сборке под винду требует Wix 3).
            +1
            Очень плотно работаю с JavaFX-TornadoFX-Kotlin.
            FatJar-ники хорошо собираются с помощью ShadoJar. В Windows проблем с построенными бинарниками нет вообще никаких, всё работает прекрасно. А вот в линуксах есть нюансы — то менюшки вылезают только на первом мониторе, то бинарник через сутки работы забирает под себя одно ядро навсегда. Проблемы известны, но не исправлены, для каких-то есть обходные пути, для каких-то нет. И самое занимательное — проблемы зависят от используемых дистрибутивах и рабочих столах, хуже всего обстроят дела с трёхклятым Asta Fly а, например, xfce работает прекрасно
              0

              Здравствуйте. Можно ссылку на упомянутый Asta Fly ? Как-то очень плохо гуглится по названию, что за DE такое.

                0
                Добрый день! Это не IDE, а рабочий стол Astra Linux с названием Fly
                0

                И можно также ещё узнать, что за десктоп приложения, которые нужно оставлять работать сутки, помимо IDE ?

                  0
                  Всё, что связано с охраной. Рабочие места дежурных, контрольно-пропускные пункты, видеонаблюдение и прочее.
            –1

            Все же раз существует так мало известных программ с UI на Java, значит есть какие-то более важные причины, нежели недостатки JavaFX

              +4
              У JavaFX проблемы с дистрибуцией и поддержкой. До относительно недавнего времени была только реализация JavaFX от Oracle (которая включалась в обычную поставку джавы), поэтому многие дистрибутивы линукса с OpenJDK вместо Oracle тупо шли лесом. Собственно, и сейчас ситуация похожа, т.к. OpenFX необходимо устанавливать отдельно в дополнение к OpenJDK.
                0
                Причины в основном две:
                1. Разработка сложнее, чем на электроне. Отмазка почти всех сервисов, имеющих веб-версию.
                2. Для работы приложения под jvm нужна сама jvm. Если простота сборки/установки/запуска разработчику важнее, чем кроссплатформенность, то пишут на шарпе под .net.
                Я больше люблю javafx (точнее tornadofx с kotlin), но сделать полный jar в моем случае можно только через костыли (по крайне мере когда я последний раз начинал писать что-то десктопное, было так). Получается, надо либо делать костыльную сборку и просить пользователя поставить jre, либо делать еще отдельный лаунчер (хотя бы батник) и пихать jvm вместе с программой (а это уже какой-то электрон-вей).
                  +1

                  Исходя из вашего комментария, стоит перети на .NET :)
                  Так как он давно кроссплатформенный, как и gui, например, AvaloniaUI, которая использует как раз рассматриваемую skia

                    +2
                    либо делать костыльную сборку и просить пользователя поставить jre, либо делать еще отдельный лаунчер

                    есть какой-то прницпиальный способ сделать по-другому? Либо компилишь под каждую платформу либо используешь что-то уже скомпиленное под каждую плафтформу. Так вроде бы будет с любым UI на любом языке.

                      0
                      В Либерику наконец-то завезли работающий jpackage
                      В JDK 16 вводится новая утилита — jpackage. Она основана на javapackager, перешедшем из Oracle JavaFX. Этот тул для упаковки автономных Java-приложений вместе со средой исполнения был впервые предложен в 14-ой версии (JEP 343) как инкубационный инструмент; теперь же он подходит для промышленной эксплуатации. Функция уже поддерживается во всех операционных системах и производит свойственные платформе файлы: msi и exe на Windows, pkg и dmg на macOS, deb и rpm на Linux.


                      Ещё у БеллСофта есть «Liberica Native Image Kit» который, по описанию, должен делать нативные бинарники на GraalVM. Но ни описания, ни api, ни примеров…
                        +1

                        Я обычным граалем компилил javafx в нативный бинарник, вроде особых проблем невидел, правда тестил на небольшом приложении

                    –3
                    Сейчас как раз над этим думаю. Написал геометрическую программу (на C++), которая хорошо рисует всякую геометрию. Теперь хочу написать к ней пруфчекер. И вот нужен язык, позволяющий функциональное программирование, но также вычислять с кватернионами и быстро рисовать. Scala сразу забраковал, интуитивно, попробую на Факторе (есть ещё OCaml, но не видел, чтобы на нём рисовали).
                      +4

                      Слушайте, ну ни слова ни сказать про SWT/JFace
                      и Eclipse — это совершенно неприлично. И даже тот факт, что это перевод, переводчика не извиняет.

                        0

                        Иначе никак?

                          +1
                          Впечатление от статьи — халтурная халтура. Можно было хотя бы постараться до ума довести машинный перевод.
                            +1
                            Какой-то лютый поток сознания, всё уже написано — бери и используй. А Skia с визуальными контролами — это Flutter, и Dart гораздо приятнее чем Java. Или же можно взять .Net
                              0
                              Или Qt. Прекрасный тул, получше шарпа. Можно вдобавок в Python ваять прототипы. По удобству прототипирования питон оставляет остальные языки далеко позади.
                                0

                                А если я java знаю? Мне теперь все бросать и бежать net учить? Весь смысл в альтернативе для jvm.

                                0
                                Они были настолько существенными, что только одной компании удалось создать прилично выглядящее приложение на Swing.


                                тот кто писал статью точно обладает каким то опытом в деле? а то знал бы как минимум еще несколько компаний крупных которые используют Java для десктопных приложений вполне успешно, например F-Secure или Interactive Brokers, а последним то надо точно отзывчивость и уровень
                                  0
                                  C# тоже подойдет, но в нем нет Clojure.

                                  Что?

                                    0
                                    Тоже удивился, на официальном сайте даже написано об Clojure CLR
                                      0
                                      Это из оригинальной статьи. Вероятно, автор имел в виду CLR и то, что под CLR нет clojure (которую он, судя по всему, любит – на ней есть несколько примеров использования в репозитории проекта).
                                      Что, впрочем, все равно неправда. Clojure под CLR есть. Даже для юнити есть.
                                      0

                                      "C # тоже подойдет, но в нем нет Clojure."
                                      А это разве не оно https://github.com/clojure/clojure-clr?

                                        –1
                                        Java: Дашь списать домашку?
                                        dotnet: Да, только не списывай точь-в-точь.
                                        Java: Skija
                                          0
                                          Skia — это отличная библиотека, но при чем тут UI? Вы же не собираетесь заново создавать все виджеты, начиная с кнопок и чекбоксов, и заканчивая многострочными полями ввода с цветами, шрифтами и вот этим всем? На это полжизни уйдет.

                                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                          Самое читаемое