Я интересуюсь приложениями с графическим интерфейсом с тех пор, как начал программировать. Создание серверного приложения, которое управляет терафлопсами операций, является впечатляющим инженерным достижением. Но цикл обратной связи при разработке настольного приложения намного короче. Это делает его, по крайней мере для меня, гораздо более мотивирующим. Это еще более верно для побочных проектов. В этом фокусе я хотел бы подтвердить состояние настольных фреймворков JVM.
Этот первый пост представляет собой введение, обрамляющее общую предысторию и обзор фреймворков, с которыми я столкнулся.
Фон
Давайте посмотрим правде в глаза: в борьбе веб-приложений против настольных приложений победили первые. Просто их развертывание обходится дешевле. Именно по этой причине люди начали настаивать на них, хотя комбинация HTML-JavaScript-CSS в то время предлагала более плохую альтернативу.
Веб-приложения сейчас распространены повсеместно: в прошлом я даже разрабатывал веб-приложения менее чем для 5 пользователей. Стоило это того или нет, я оставляю это на ваше усмотрение.
Победа веб-приложений подтолкнула настольные приложения к устареванию. Большинство из тех, кто избежал этой участи, используют Electron framework/ | например, Slack, VS Code, Postman и т.д. JavaScript и Electron имеют несколько преимуществ:
- Многие разработчики знают JavaScript. Фреймворк, основанный на JS, позволяет разумно использовать эту доступную рабочую силу.
- JavaScript не требует какой-либо платформы. Такие приложения являются автономными.
- Electron доступен с открытым исходным кодом, по лицензии MIT и управляется Фондом OpenID.
С другой стороны, Electron печально известен своей ресурсоемкостью.
AWT и качели
Abstract Windowing Toolkit был графическим фреймворком, первоначально включенным в JDK. AWT полагается на собственные ресурсы операционной системы: компоненты AWT являются/| тяжеловесными . Java 1.2 представила Swing, альтернативу AWT, которая предлагала облегченные компоненты.
Я начал изучать Java два десятилетия назад и также пытался изучить Swing. Но в то время я не работал ни над какими проектами настольных приложений во время моей работы. У меня также не было времени ни на какой личный сайд-проект. Тем не менее, мой интерес был там.
Swing предлагает способ настройки внешнего вида приложения. По умолчанию используется LAF , но также доступен LAF операционной системы. Поскольку Swing рисует компоненты сам по себе, даже с последним, компоненты всегда выглядят немного иначе, чем в родной ОС. IntelliJ IDEA – известный пример успешного Java-приложения.
На протяжении многих лет я продолжал пробовать Swing, но также и другие доступные варианты.
СВТ
Первый такой вариант на самом деле был взломом популярного Eclipse IDE . Eclipse не использовал ни AWT, ни Swing. Разработчики разработали свой графический фреймворк – Стандартный инструментарий виджетов. SWT полагался на собственные библиотеки.
Хитрые разработчики использовали тот факт, что Eclipse был с открытым исходным кодом, чтобы создавать свои приложения поверх него. Через некоторое время проект Eclipse официально признал это. Они работали над улучшением API, документации, библиотек и назвали это платформой Rich Client Platform.
За эти годы я пару раз играл с SWT. Мне очень понравилось, как он использовал собственные компоненты ОС. Это давало настоящее родное чувство. Никто не знал, что под ним находится Java-приложение.
Eclipse также выпустила абстракцию более высокого уровня поверх SWT под названием JFace. Не путайте его с JSF , это вообще не связано.
Самая большая проблема с SWT заключалась в том, что API был нестабилен. Это начиналось как внутренняя структура, и это было заметно. Обновление до новой младшей версии нарушило мой код.
Еще одна проблема, которая затронула меня меньше, связана с зависимостью от компонентов операционной системы. Java разработана как кроссплатформенная: следовательно, каждая среда выполнения Java поставляется со своими привязками компонентов для ОС, на которой она установлена. SWT также имеет привязки для каждой ОС, но на уровне JAR. Следовательно, приложения должны объединять определенный JAR-файл для каждой операционной системы, на которой он должен быть развернут.
Сгибать
Нужно помнить контекст 15-летней давности. HTML5 все еще был проектом W3C. Браузеры отличались отображением HTML-кода. Иногда у них также были разные интерпретации JavaScript. Создание настоящего кроссбраузерного приложения потребовало больших временных затрат.
В 2004 году Macromedia выпустила Flex, фреймворк, способный создавать Flash-приложения из:
- Определения графического интерфейса, определенные в XML, с использованием определенной схемы XML
- Поведение, закодированное в ActionScript
Единственным требованием было наличие в браузере плагина Flash. В то время он был установлен в 90% браузеров!
Виджеты предлагали гораздо лучший интерфейс, чем их HTML-эквиваленты. Например, фильтрация в поле со списком была доступна в каждом тяжелом клиентском фреймворке уже целую вечность. Фильтрация не была невозможной, но была неразбериха с HTML и JavaScript. Flex снова смог сделать это легко.
Это также позволяло разработчикам внедрять приложения, которые выглядели приемлемыми даже при плохих навыках работы с интерфейсом. Кроме того, внешний вид был одинаковым во всех браузерах. Для меня это было больше, чем альтернатива убогому спагетти-коду JavaScript: я считал, что Flex – это |/способ создания приложений.
Затем появился iPhone . Это кардинально изменило то, как люди пользовались Интернетом, от настольных компьютеров до мобильных телефонов. Теперь проблема заключалась в том, что Flash потреблял много энергии (и, честно говоря, это также представляло большой риск для безопасности). Стив Джобс запретил вспышку на айфонах, чтобы сэкономить на энергии. С появлением мобильных телефонов это делало Flash все менее и менее привлекательным для разработчиков.
В конце концов, Adobe, которая купила Macromedia в 2006 году, передала технологию Apache foundation. Боюсь, это был последний шаг перед концом: последняя версия выпущена в 2017 году, а последнему коммиту в репозитории Git 9 месяцев.
Другие попытки
Смерть Flash и расцвет HTML5 и JavaScript произошли не мгновенно. Долгое время не было явного победителя. В тот период выбор одного из них перед другим был кошмаром архитекторов.
Конец Flash сделал OpenLaszlo неактуальным.
Мне известно о двух других инициативах:
- Mozilla предложила XUL, способ определения графических компонентов
- Microsoft придумала Silverlight, конкурента Flex
И то, и другое в настоящее время устарело.
JavaFX также заслуживает упоминания. Версия 1.0 была выпущена в 2008 году, примерно в то время, когда Flex уже был хорошо зарекомендован. Это было даже несопоставимо. Интересно, что Oracle продолжила разработку: после приобретения Sun в 2010 году она выпустила версию 2.0 в 2011 году.
Насколько я понимаю, на данный момент JavaFX не является частью JDK. Компания Gluon, похоже, лидирует в своих разработках. Это делает JavaFX доступным в виде стандартной библиотеки JAR, опубликованной на Maven Central (и в виде обычной загрузки).
Развертывание настольных приложений Java
Как я уже упоминал, ранее Интернет предоставлял плохой пользовательский опыт по сравнению с толстыми клиентами. И все же он выиграл битву. Я считаю, что причина двоякая:
- Толстые клиенты либо предназначены для конкретной ОС, либо требуют платформы например a Среда выполнения Java .
- Развертывание приложения на одном сервере (или даже на их кластере) проще и требует меньше времени, чем на каждом пользовательском компьютере
Для внутренних пользователей ни один из аргументов не выполняется. Компьютеры внутри компании централизованно управляются (или должны управляться) командой системных администраторов. Таким образом, можно установить любое программное обеспечение удаленно через сеть. Предприятия уже давно используют такое специализированное программное обеспечение.
В мире Java специально для этого было разработано несколько решений.
Java Web Start – это решение, предложенное Sun как часть платформы Java. С помощью JWS создается внешний дескриптор развертывания, использующий формат JNLP. Дескриптор определяет: класс для запуска, необязательные зависимости, аргументы JVM и т.д.
Затем файл дескриптора становится общедоступным, например, размещенным на веб-сервере. JWS может проанализировать его, загрузить необходимые зависимости и соответствующим образом запустить JVM.
Банки могут автоматически обновляться с помощью JWS. JWS может загружать только разницу между установленным JAR и подлежащим загрузке JAR. Еще лучше, если патч имеет больший размер, чем JAR, он загружает последний.
Если приложение использует общую базу данных, изменение схемы может быть проблемой. Например, как синхронизировать обновления между различными клиентами и базой данных? Команда разработчиков может разработать приложение, поэтому оно не может быть запущено, если оно не выше определенной версии.
Oracle устарела от JWS в Java 9 и удалила ее из дистрибутивов Java 11. Теперь он доступен как проект с открытым исходным кодом GPL2 и спонсируется швейцарской компанией Karakum .
Другой вариант развертывания доступен для приложений, использующих SWT. IDE предлагает возможность автоматической загрузки плагинов обновлений с настроенных удаленных сайтов. Эта функция предоставляется модулем под названием RCP . После того, как вы установили приложение, RCP позаботится о загрузке и установке последней версии. Вы можете использовать RCP для создания приложений и пользоваться функцией автоматического обновления.
Вывод
Веб-приложения выиграли борьбу с настольными приложениями. Но настольные приложения Java по-прежнему актуальны внутри компании. Все технологические компоненты находятся в свободном доступе: JDK и библиотеки.
В каждом будущем посте из этой серии я буду разрабатывать простое приложение, используя единую технологию. На следующей неделе мы посмотрим на Swing.
Чтобы идти дальше:
- “След: Создание графического интерфейса С помощью Swing”
- Учебное пособие по SWT
- Учебное пособие по Eclipse Rich Client Platform
- Apache Flex
- JavaFX
- Открыть веб-Запуск
Первоначально опубликовано на Фанат Java в январе 3 – й 2021
Оригинал: “https://dev.to/nfrankel/the-state-of-jvm-desktop-frameworks-introduction-2jle”