Данную статью попросили написать коллеги, ибо в связи с малой популярностью Java-десктопа достаточно трудно встретить разработчиков, которые применяли бы OpenJFX для сложных и амбициозных пет-проектов.
Разрабатывая собственный JavaFX-фреймворк несколько лет, я, конечно же, буду подвержен когнитивным искажениям, а статья будет плавно скатываться к субъективизму и философии. Поэтому стоит сразу вспомнить такие феномены как: профессиональная деформация, склонность к подтверждению своей точки зрения, эффект знакомства с объектом и подобные им. Конечно же, синдром утёнка, который присутствует у многих разработчиков (и у меня в том числе) тоже может хитро маскироваться в рассуждениях. Для понижения влияния этой команды негативных эффектов я буду стараться использовать различные источники и рассматривать изучаемый предмет с разных сторон, хотя бы это и может выглядеть достаточно наивно или занудно.
Начать следует с самого главного холиварно-философского вопроса о десктопе в Java. Перекос Java-инфраструктуры в бэкенд - это общеизвестный факт, что ведёт к размножению комментариев и мнений в сети рода "десктоп на Java не пишут". Меня всегда удивлял такой подход, поскольку он выглядит каким-то уж очень подозрительным, ибо разработчики обычно радуются возможностям языка и чем их больше - тем лучше. Я участвовал в самых разных языковых комьюнити и в общем-то нигде не припоминаю такого неприятия какой-то области языка, будь то бэкенд, десктоп или какая-то очень и очень узкоспециализированная специфика.
Более того, GUI-программы пишут на очень редких и своеобразных языках программирования, которые очень и очень на любителя, да и там никто не жалуется. А Java предоставляет знакомый и привычный синтаксис С-семейства, множество удобств, библиотек и возможностей, которыми грех не воспользоваться, что создаёт некоторый когнитивный диссонанс: возможности вроде как и есть, но они почему-то не нужны, почему... это хороший вопрос.
После более плотного знакомства с Java-комьюнити ответ на этот вопрос я, конечно же, знаю, поэтому статью можно было бы закончить на этом абзаце, но прямой ответ многим бы не понравился, а особенно хейтерам Java-десктопа. Так что пойдём объёмным и занудным обходным путём.
Итак, в социальной сети размещается пост с материалами по JavaFX, далее под ним кто-то пишет комментарий "JavaFX мертв", если находятся возражающие, то они отвечают, если нет, то нет. Побудем занудами и позаимствуем определение смерти с Википедии, где смерть - прекращение, полная остановка биологических и физиологических процессов жизнедеятельности организма. Применим данное определение аналогией к JavaFX, не теряя его смысла, с доказательством от обратного: предположим, что JavaFX мёртв.
Это значит, что должно наблюдаться полное прекращение процессов разработки, сопровождения и использования тулкита. Посмотрим зеркало репозитория openjdk-jfx: в ветку develop идут фиксы багов, открываются новые в багтрекере. За месяц, с 28.08.2019 по 28.09.2019 - 8 активных пулл-реквестов, 4 влиты в ветку, 22 проблемы, из них закрыто 3, открыто 19. Последний коммит несколько дней назад. Трудно оценить степень такой активности из-за сложности и монструозности тулкита, но это какая-никакая активность.
Рассылка разработчиков openjfx-dev активна. На сайте openjfx.io доступны несколько версий в т.ч. раннего доступа. По тегу "javafx" на StackOverflow достаточно много ответов, вопросы бывают с периодичностью в несколько часов.
Отсюда мы не можем говорить о полном прекращении жизни JavaFX, это было бы грубым нарушением логики определения смерти. Значит вопрос стоит о какой-то степени активности. Раз вводится понятие степени, то должна быть шкала или ранжирование, а самих элементов множество, иначе мы не может знать, насколько "жив" и "мертв" различаются между собой. Так как мы не можем сравнивать две совершенно разных технологии, например, веб и десктопный тулкит, то должны бегло изучить инфраструктуру десктопного рынка, чем и займемся.
Я буду опираться на несколько статей, которые находятся в топе Google, полагая, что большая часть новичков и непрофессиональных пользователей будут ориентироваться на них. В статье 9 Must Decisions in Desktop Application Development for Windows приводится ссылка на исследование 2016 года по выбору технологии для Windows: на первом месте WPF, WinForms, UWP. Следом за ним Electron и все остальные.
Сразу есть смысл выделить два больших класса приложений: платформозависимые и кроссплатформенные. В качестве кроссплатформенных решений приводятся Electron, Qt, Swing, JavaFX. Этот список можно также дополнить Avalonia, Flutter, который уже начинает ориентацию на десктоп. JavaFX является кроссплатформенным тулкитом, что будет отражаться на архитектуре, функционале и всём остальном. Мы не можем однозначно сравнить платформозависимый тулкит и кроссплатформенный за счет их большой архитектурной разницы. Платформозависимый будет иметь более развитый функционал, но при отказе от платформы вся кодовая база или её часть потеряется, кроме того, инструменты - IDE, процессы сборки, библиотеки и т.п. также могут быть зависимыми от операционной системы и нет, как и вся инфраструктура.
С другой стороны, нельзя рассматривать их как два разных рынка в силу малого распространения альтернативных операционных систем. По данным netmarketshare.com на август 2019 доли Windows/Mac/Linux относятся как 87.50%/9.74%/2.14% соответственно. Поэтому в мировом масштабе фреймворки могут быть прямыми конкурентами, в региональном - в зависимости от разных условий, например, отношения бизнеса к свободному софту: из-за жёсткой борьбы с пиратством для части мелких контор закономерен поиск снижения издержек за счет наличия только одного компьютера с Windows, как правило, для бухгалтера. Компьютеры сотрудников, менее зависимые от специфического софта могут более безболезненно переводиться на Linux, могут проводиться политики импортозамещения или подобные им. Например, для технических специалистов доля Linux может резко возрасти.
Рынок мог оказывать влияние даже на создание JavaFX: для Oracle излишнее вложение ресурсов на разработку тулкита в условиях доминирующего положения Windows выглядит такой себе затеей, кроме того, в случае явной конкуренции это могло вызвать ответные меры со стороны Microsoft. А замена устаревшей технологии для целей поддержки Java-инфраструктуры вполне логична и вписывается в необходимость.
Какой вывод напрашивается: на степень популярности тулкита будет влиять рынок, а на рынок наиболее сильное влияние оказывает доминирующая с большим отрывом операционная система. Мы не можем так просто сравнивать популярность кроссплатформенных решений и сильно\частично платформозависимых, получается, что мы сравниваем между собой сильно различающиеся инструменты. Так как Windows имеет C#-зависимые инструменты, то в мировом масштабе у других решений будет меньшая популярность, которая зависит от разных факторов. Каких факторов...
Относительно кроссплатформенных приложений в статье приводятся примеры выбора инструментов:
- В случае веб-продукта, наличия подходящих библиотек и любой ориентации на веб предпочтителен Electron.
- В случае наличия Java-программистов - Swing, JavaFX.
- В случае взаимодействия с C++ приложениями, требованиями к производительности - Qt.
Мы видим, что выбор инструмента определяется каким-то набором правил, которые опираются на преимущества тулкитов. Если в случае веба и производительности они технического характера, то в случае JavaFX это наличие программистов.
Кроме того, за каждым тулкитом стоит инфраструктура языка, который возник на основе наличия проблем в других языках. Например, позиционирование Java на рынке использовало преимущества высокоабстрактного языка с уклоном на объектный анализ с архитектурой. Трудно сказать, сыграло ли это главную роль в занятии доли рынка, но факт остается фактом: другой язык либо решает проблему, либо дает какое-то преимущество, за счет чего и существует огромное множество различных языков. Это также вводит ограничение - универсального языка программирования нет. Если бы он был, то необходимость во всех остальных языках отпала бы, хотя и с задержкой из-за вымирания наиболее опытных разработчиков, которые никогда не будут терять свой опыт и планку зарплат, переходя на лучший, но менее выгодный для них новый язык программирования. Из-за разброса разработчиков по разным коммьюнити наблюдаются перекосы: в одном языке много простых библиотек, но мало специфических, в другом - наоборот и т.п, что сильно влияет на возможность выполнения требований.
Существуют самые различные виды требований к продуктам. Например, в статье указывается стратегия развертывания, удобство и наличие установщика, возможность непрерывной интеграции, логирование, темизация приложения, лицензирования и подобных им, которые корнями уходят в функциональный и нефункциональные, FURPS и прочие требования. Через цепочку косвенных связей на них будут влиять не только архитектура и сам тулкит, но инфраструктура языка, сторонние библиотеки, устоявшиеся приемы, квалификация разработчиков и другие зависимости. Интуитивно, что в разных языках часть требований будет лучше чем в других, а часть - хуже.
Для решения технической задачи и выбора десктопного тулкита нужно учитывать:
- Надсистему - язык и его инфраструктуру
- Сам тулкит - его возможности и функционал
- Подсистему - особенности работы и квалификация разработчика
Например, команда Microsoft, работая с веб-тулкитом может решить практически любой спектр задач за счет наличия возможности запроса помощи из других отделов, отлаженной системы тестирования, наличия программистов узкой специализации и других преимуществ, которых, конечно же, не будет у маленькой команды в небольшом городе.
Какой вывод напрашивается: на фоне меньшей популярности и в условиях наличия платформозависимых альтернатив, для решения технической задачи кроссплатформенным тулкитом существует зависимость от множества различных факторов, что еще больше сужает популярность некоторых решений.
С другой стороны, есть определенный класс приложений, для которых выбор сделать намного легче. Не будем далеко ходить, и вспомним некоторые категории приложений, позаимствовав их из статьи Best Frameworks for Desktop Application Development:
- Автономные (коробочные) бизнес-приложения.
- Клиент-серверные приложения.
- Программное обеспечение совместной работы
- Утилиты
- Системные приложения
- Мультимедиа приложения
- Сетевые приложения
Нельзя назвать данную систематику совершенной: в одном случае признак, по которому производится деление относится к архитектуре (клиент-сервер), в другом - к решаемой задаче (мультимедиа). С другой стороны, для беглого рассмотрения этого может быть достаточным и позволяет сделать несколько грубых выводов.
Мультимедиа, системные приложения достаточно сильно связаны с системой. За счет приведенной выше структуры рынка операционных систем кроссплатформенным тулкитам нужно намного больше ресурсов, чтобы сравниться с функционалом платформозависимых, для большей части задач может хватить и версии под самую распространенную систему.
Какой вывод напрашивается: на фоне меньшей популярности, в условиях альтернатив и сложного влияния разных факторов для кроссплатформенных решений лишь некоторый класс задач дает преимущество, в ином случае рождая дополнительные риски. А это также сказывается на популярности.
Риск потери пользователей на альтернативных системах может быть намного меньше риска получения низкокачественного продукта на всех системах и банкротства из-за невозможности соблюсти критические требования.
Стоит ли ожидать сильного роста популярности и так малопопулярного инструмента. Думается, что нет. Основные тренды 2019 года были связаны с развитием новых технологий виртуальной и дополненной реальности, искусственного интеллекта, блокчейна, ростом популярности JavaScript, развитием IoT, PWA.
Кроме того, в конце 2018 года на OpenSource лицензию были переведены Windows тулкиты WPF, Windows Forms, WinUI. Трудно оценить этот шаг из-за масштаба Microsoft и многовариантных маневров, но можно грубо предположить, что открытие исходного кода менее вероятно в условиях высокой бизнес-ценности продукта. Активное развитие Visual Studio Code, упрощение сопровождения последних версий Windows(Уволенный сотрудник Microsoft объяснил, почему в Windows стало так много багов) постоянно появляющиеся материалы о проблемах десктопного софта с 2017 года, например, Is desktop software dead по настоящее время также говорят об опасениях наблюдателей, снижении интереса к десктопу со стороны гигантов индустрии или других проблемах.
В таких условиях маловероятно ожидать увеличения популярности и без того прикладных решений в том числе и JavaFX.
Результирующий вывод: на популярность инструмента влияет множество факторов, начиная от глобально-мировых и заканчивая местными региональными. Технические особенности и функционал тулкита играет важную, но не главную роль в случае выбора технологии. JavaFX основан на Java, прямо не связан с C# и не может иметь популярность в условиях доминирующей операционной системы на рынке.
Давайте бегло рассмотрим непосредственно рынок JavaFX.
На сентябрь 2019 года по данным поисковой системы Indeed на США приходится всего 70 рабочих мест по ключевым словам "javafx", часть вместе со Swing и AWT. hh.ru: 7 вакансий, большая часть из которых без специализации на тулките. По данным jobs.tut.by, hh.ua, work.ua нет вакансий. При добавлении к запросу “java” количество вакансий возрастает.
Можно сделать грубый вывод, что в мировом масштабе не существует как таковой специализации на JavaFX, а большую часть очень простых задач, вероятно, может решить обычный java-разработчик.
Насколько десктопное программирование развито в самой Java-инфраструктуре? Например, по ссылкам разной степени давности Блеск и нищета Java для настольных систем
, Why is Java desktop considered to be dead?, Java Desktop Application industry можно уследить, что не существует однозначного класса задач, которые бы дали преимущество в случае Java-десктопного приложения или анализ при выборе инструментов порой упрощен.
Сдерживающим фактором может быть большое количество проблем в самом тулките. В JavaFX до сих пор не исправлено несколько критических для использования проблем: поддержка трея, локализация контекстных меню, случайные графические артефакты, юзабилити таблиц и т.п.. Кроме того, модульность в Java 9 создала новые проблемы в виде конфликтующих библиотек и сложности интеграции плагинов. Это всё может отталкивать разработчиков и приводить к уменьшению использования тулкита или стимулировать переход на другие технологии.
Основным преемником прав на тулкит является Gluon, который строит свой бизнес вокруг мобильных технологий. Неизвестно, что будет в случае падения коммерческого интереса к тулкиту. Некоторые разработчики могут рассматривать это как дополнительный риск. В маркетинге Gluon не представлен десктопный сегмент, кроме того, расположение ссылки на тулкит в меню Products может оттолкнуть разработчиков открытого кода.
С другой стороны, включение JavaFX в состав Zulu JDK с официальным обоснованием как потребность клиента, наличие собственного сайта, версии под ARM-архитектуру на основе Liberica, проведение конференций, частые минорные обновления и другие моменты говорят о более лучшем положении тулкита после отделения от jdk.
Косвенно, количество разработчиков может увеличиться из-за распространения курсов программирования и моды на него в среде молодежи. Java стабильно занимает топ различных рейтингов и эксплуатирует стереотип высоких зарплат. Даже в случае невозможности трудоустройства часть разработчиков может пожелать использовать тулкит для личных целей вместо изучения альтернатив.
Таким образом, так как выбор JavaFX в качестве технологии зависит от многочисленных факторов, часть из которых носят нетехнический характер, то популярность будет зависеть еще и от методологии анализа, применяемой в бизнесе, отстаивания частных интересов заинтересованными лицами или невозможностью оценить степени риска. Действительно, в условиях высокой степени неопределенности многие будут выбирать наиболее проверенные варианты, чтобы в случае провала (даже из-за других факторов) они не были уличены в ошибочном решении, поэтому доля малопопулярных решений будет еще больше снижаться из-за человеческого фактора.
Трудно сказать, улучшилось ли положение JavaFX после отделение от JDK. Формально - да, поскольку Gluon проводит необходимые меры пиара, однако вопрос в том, что мы не знаем процент java-разработчиков для которых отделение от JDK было сигналом прекращения поддержки либо серьезным риском. Много ли их было... если да, то JavaFX-инфраструктуре был нанесен серьезный урон.
Для комплексного характера статьи можно попробовать смоделировать задачи, на которых JavaFX имеет преимущества. К сожалению, за недостатком информации дальнейшее рассуждение будет носить субъективный характер.
По итогам активного мониторинга JavaFX-инфраструктуры, ведения паблика во Вконтакте мне встречались следующие основные применения:
- Внутренние разработки и специализированные приложения для личного использования в т.ч. внутрикорпоративного.
- GUI-обёртки над более трудоёмкими библиотеками и api.
- Тонкие клиенты как дополнение к другим java-приложениям.
- Учебные проекты.
- Хобби-проекты.
Наличие тонких клиентов как вспомогательных инструментов подтверждается частым наличием в вакансиях javafx наряду со всем стеком java-бэкенда. Есть примеры CRM, производственных, вспомогательных приложений в личных блогах и сайтах ведущих javafx-разработчиков, достаточно крупных хобби-проектов, которые могут использовать пожертвования или служить для портфолио как, например XR3Player.
Что касается распространения JavaFX на мобильных устройствах, то у меня нет достаточных примеров за небольшим исключением, например, статьи 2017 года JavaFX Real-World Apps: Monastery Disentis или косвенных материалов, навроде JavaFX on mobile - any one tried?. За счет наличия сильных конкурентов и зрелой инфраструктуры в мобайле в т.ч. интеграции туда веб-стека и развития технологии PWA достаточно трудно оценить применимость JavaFX вне специфических задач.
Основные конкуренты тулкита: в мире java - Swing и Awt. Кроссплатформенные Electron js, Qt, Gtk, Avalonia, Flutter и т.д. Вторичные конкуренты в контексте операционных систем: WPF\UWP\WinForms.
Часто можно услышать мнения о свободной заменяемости Swing и JavaFX. Это крайне сомнительное утверждение из-за сильного отличия их по концепциям и возможностям. Для оценки применимости той или иной десктопной технологии оценивающий должен быть плотно связан с десктопом и графикой. Поскольку в Java-комьюнити подавляющее количество разработчиков специализируется на бэкенде и фронтенде, то любые оценки от специалиста совершенно другой области будут иметь повышенный шанс быть неверными, что часто и происходит.
Поскольку многие java-приложения служат лишь клиентом для обращения к базе данных, то часть задач может быть решена без JavaFX и дополнительных возможностей, здесь обычно вспоминается Swing. Однако при усложнении задач разные тулкиты начинают демонстрировать всё больше отличий и преимущества будут сдвигаться в сторону JavaFX, особенно архитектурные.
Возможен скрытый спрос со стороны индивидуальных предпринимателей с потребностью в узкоспециальном софте, задачи которого не могут решить имеющиеся решения или их доработка будет стоить дорого. Часть из них не обладают специальными знаниями и не могут перенести бизнес-процессы в электронный вид, а также рассчитать риски внедрения. Для некоторых задач клиент-серверная архитектура избыточна и ведет к дополнительным рискам безопасности даже в пределах локальной сети. В случае наличия агрессивных конкурентов, которые могут инициировать взлом инфраструктуры, возможен интерес к десктопным приложениям.
С одной стороны, конкурирующие фирмы на основе веб-стека скорее всего будут делать упор на возможность масштабирования или интеграции в другие системы, поэтому в случае плохо определенной задачи их аргументы будет трудно опровергнуть. С другой стороны, веб-стек ограниченно интегрируется в систему, а эволюция приложения может требовать всё больше и больше системного доступа, использование низкоуровневых библиотек и личных данных, что рано или поздно может стать проблематичным для веб-стека.
Нельзя забывать и особенность DSL-тулкитов в лишних багов от управления стейтом или асинхронности, которые обычные классические тулкиты старой школы не имеют. Кроме того, чрезвычайно широкая кроссплатформенность тулкитов последних поколений сильно повышает их сложность, что будет отражаться на количестве багов, постоянных поломках апи при обновлении, проблемах от тулчейна и прочего. Специализированный на десктопе инструмент может здесь решить задачу лучше как за счёт общей простоты своего устройства, так и за счёт юзабилити контролов, которые проблематично сделать одновременно удобными под все устройства.
С другой стороны, нельзя сбрасывать со счетов перекос Java в сторону бэкенда, как я отмечал в самом начале статьи. В таких условиях выбор менее популярного инструмента действительно несет повышенный риск в случае неправильного построения стратегии его использования.
Например, для новичков изучение малопопулярного инструмента может нанести вред и сделать их менее конкурентноспособными по определённым вакансиям в сравнении с другими. Трудно сказать, что может нанести тулкиту больший вред, наличие популярности в условии хаотично насыщаемого рынка программирования или её отсутствие с возможностью развиваться более медленно, но стабильно.
Подведем итоги. JavaFX - не может быть мертвым и является инструментом для узких задач, преимущество которого зависят от множества факторов в т.ч. от квалификации лица, принимающего решение о внедрении. Заявление о смерти узко прикладных инструментов и языков обычно всегда ошибочны, ибо подобные инструменты рассчитаны на определенный круг специалистов, которые знают, что им нужно и не зависят от общей массы. Здесь можно уловить аналогию между популярной музыкой и андеграундом, литературой, искусством и т.п. разделениями почти всех отраслей нашей жизни. Несмотря на большой класс проблем, узкоспецифические отрасли\инструменты\технологии обычно всё равно кем-то востребованы и за счет этого держатся на плаву.
В любом случае, не стоит забывать и о будущем. Завтра всё может измениться, технологии рождаются и умирают, это происходило всегда и будет происходить вечно. Что будет с JavaFX завтра? Трудно сказать, может быть тулкит станет лучше, а может и погибнет в жестоких конкурентных войнах, где принцип Vae victis, как ни парадоксально, является двигателем эволюции технологий. Поживем, увидим...