JFC против AFC: Какой графический интерфейс лучше?

Пакет AFC, предлагаемый корпорацией Microsoft, представляет собой альтернативу JFC Swing. В его состав входят:

Заметим, что AFC не поддерживает технологию drag-and-drop, но разработчик может встроить в приложение возможности drag-and-drop, если воспользуется пакетом Microsoft Java Software Development Kit (SDK).

Основное внимание в нашей статье будет уделено сравнению JFC Swing и AFC. Кроме того, мы кратко коснемся средств работы с двумерной графикой и технологией drag-and-drop, а также рассмотрим доступность, простоту освоения и возможности применения обоих пакетов. Для удобства аббревиатура "JFC" будет применяться для обозначения любой составной части пакета.

Философия проекта и общая архитектура

Возможности пакетов JFC и AFC по созданию графического интерфейса существенно превосходят возможности библиотеки AWT, входящей в состав JDK. Кроме того нельзя не отметить улучшенную производительность и адаптируемость к использованию на самых различных платформах. И JFC и AFC располагают широким набором средств, позволяющих эффективно встраивать различные элементы GUI в большинство приложений Java. Библиотеки JFC и AFC разрабатывались с целью:

И все же, несмотря на внешнее сходство, в основе AFC и JFC лежит принципиально различная архитектура:

В кардинальном отличии архитектур AFC и JFC нет ничего удивительного. В конце концов, AFC претендует на вытеснение AWT, хотя специальные средства и обеспечивают совместимость данной библиотеки с компонентами AWT. Пакет JFC является расширением AWT. Он базируется на архитектуре AWT, к которой добавляются мощь технологи MVC и достоинства модульного построения.

Модели обработки событий и их быстродействие

В технологиях JFC Swing и AFC применяются различные подходы к поддержке моделей обработки событий, реализованных в JDK 1.0 и 1.1. Как результат, существенно отличается и их быстродействие.

JFC Swing базируется исключительно на модели делегирования событий JDK 1.1. Частично это объясняется тем, данная модель явилась основой для внутренней реализации некоторых компонентов JFC. Обычно классы JFC, отвечающие за взаимодействие с пользователем, должны вести учет всех событий и в зависимости от этого определять дальнейшее поведение программы. Класс обычно регистрирует для элемента управления связанный или даже свой собственный код, который выступает в роли интерфейса-слушателя соответствующих компонентов. Взаимодействие между компонентами классов JFC и конкретной программной реализацией пользовательского интерфейса, как правило, основывается на модели делегирования или передачи событий. К примеру, класс дерева JFC для отслеживания событий, которые генерируются мышью, регистрирует себя в качестве интерфейса-слушателя компонента JTree. Вследствие новой политики обработки событий, применяемой в JDK 1.1 и построенной по принципу "все или ничего", нельзя гарантировать безопасного получения и дальнейшего распространения событий, поддерживаемых версией 1.0.

Для внесения ясности стоит отметить, что хотя JFC и является расширением JDK 1.1 AWT, которая обладает обратной совместимостью с моделью событий версии 1.0, сами компоненты JFC не наследуют эту совместимость. Модель событий AFC представляет собой гибрид моделей JDK 1.0 и 1.1. Она обеспечивает поддержку API 1.1 на базе реализации модели 1.0. В отличие от подхода "все или ничего", характерного для JDK, интерфейс AFC переадресует все события версии 1.1 классу, находящемся на более высоком уровне иерархии, как будто эти события относятся к версии 1.0.

Разработчикам следует учесть, что хотя AFC и поддерживает API модели событий 1.1, эта технология не позволяет воспользоваться всеми преимуществами модели событий JDK 1.1, которая исключает дублирование и распространение нежелательных событий. При использовании библиотеки AFC интерфейс-слушатель событий версии 1.1 регистрируется в контейнере и может быть переключен данным контейнером на обработку событий версии 1.0. Таким образом, производительность приложения не только не увеличивается, но и рискует еще больше снизиться, если приложение одновременно будет использовать модели событий версий 1.0 и 1.1. По нашему мнению, модели событий AFC свойственны серьезные недостатки, не позволяющие повысить быстродействие и масштабировать сложные приложения. При использовании только модели событий JDK 1.1 приложения JFC могут достичь самой высокой производительности, уменьшив одновременно трафик событий. Однако условие поддержки технологией JFC только модели событий версии 1.1 приведет к тому, что все приложения, совместимые с версией 1.0, придется переписать для обновленной версии JFC. С другой стороны, библиотека AFC обеспечивает самый простой способ переноса приложений, использующих модель событий старой версии 1.0.

На рисунке проиллюстрирована разница между моделями событий AFC и JFC. При нажатии кнопки приложения AFC генерируют четыре события, в то время как программы JFC ограничиваются лишь одним.

Предполагается, что слушатель ActionListener зарегистрирован для кнопки, а слушатель MouseListener - для панели.

Модель событий AFC (гибрид моделей событий AWT 1.0 и 1.1)

Два вызова метода postEvent пересылают событие AWT 1.0 MouseEvent из компонента в его контейнер, а событие actionPerformed активизирует слушателя ActionListener, зарегистрированного для кнопки. Обратите внимание на то, что активизируется и слушатель MouseListener, также зарегистрированный для панели. Это связано с тем, что на панели генерируется событие AWT 1.0 MouseEvent.

Модель событий JFC (подходит только для модели событий AWT 1.1)

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

Гибкость и возможности расширения

При создании приложений с графическим интерфейсом разработчики обязаны обратить особое внимание на:

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

Иногда единственным возможным вариантом расширения функциональности является разбиение компонентов AFC на подклассы или встраивание интерфейсов AFC UI. Данный подход представляется и наиболее простым. Используя многочисленные методы, реализованные в высокоуровневых классах компонентов UI, не так уж сложно разработать собственные компоненты (являющиеся производными от классов или подклассов UI), которые органично впишутся в систему AFC.

Расширить систему JFC можно тремя основными способами:

1. Если необходимо сохранить определенный стиль экранного интерфейса, можно либо воспользоваться стандартными конструкциями JFC UI, либо дополнить необходимыми функциями уже имеющиеся наработки.

2. Структуры данных, используемые в компонентах JFC, обладают хорошей расширяемостью. Каждый компонент JFC содержит ссылку на интерфейс модели данных и позволяет встраивать этот интерфейс по умолчанию. Разработчики часто обращаются к модели данных, реализованной по умолчанию, дополняя ее собственными расширениями или заменяя некоторые функции.

3. Если библиотека JFC не содержит нужного компонента, а предыдущие два метода не позволяют добиться желаемого результата (не удается создать требуемый компонент на основе имеющихся подклассов JFC GUI), можно попробовать напрямую обратиться к конструкциям AWT Lightweight UI и получить новый компонент на базе высокоуровневых классов AWT или JFC Swing. Архитектура JFC MVC, в которой графический интерфейс отделен от специфических структур данных приложения, снижает необходимость вывода компонентов GUI из базовых классов. При разработке приложений на базе технологий AFC или AWT создание графического интерфейса на основе логики приложения практикуется значительно чаще.

Что касается гибкости, JFC предоставляет программистам возможности тонкой настройки и изменения структуры компонентов GUI в процессе разработки, а пользователи могут настраивать интерфейс по своему вкусу уже во время выполнения программы. Поскольку в пакете AFC отсутствует такое средство, как MVC, а для улучшения интерфейса нельзя использовать дополнительные модули, корректнее было бы сравнить возможности, имеющиеся в обоих программных продуктах. Одним из таких свойств является гибкость объединения различных компонентов при создании пользовательского интерфейса. В общем случае AFC позволяет добавить фактически любой элемент, сделав его "наследником" уже имеющегося компонента. В частности, с помощью средств пакета можно не только сделать любой элементарный компонент (например, кнопку или поясняющую надпись) дочерним узлом более сложной конструкции дерева, но и встроить в интерфейс дерево в качестве дочернего компонента кнопки или поясняющей надписи. Другим примером может стать компоновка узлов дерева из составных элементов (списков, комбинированных списков и даже таблиц). Конкретные способы встраивания компонентов жестко не регламентируются и оставляют достаточно широкий простор для творчества. С другой стороны, несмотря на тот факт, что каждый компонент JFC является подклассом контейнера AWT и может программным путем встраиваться в любой другой компонент JFC, добавление сложных элементов к простым зачастую может приводить к неожиданным результатам. Это обусловлено двумя причинами:

Мы не собираемся подробно обсуждать концепцию средств Renderer и Editor, однако рассмотрим основные трудности, которые могут возникнуть в процессе отображения набора сложных, разноплановых элементов при обработке составных компонентов JFC механизмом Renderer/Editor. Подход, используемый в пакете AFC, значительно проще, понятнее и обеспечивает большую гибкость.

Интеграция с AWT

Компоненты AFC UI несовместимы с AWT, поскольку они не поддерживают иерархию этой библиотеки классов. Компоненты AFC нельзя поместить в контейнер AWT. (Например, класс UIButton нельзя использовать совместно с классом Panel AWT.) Однако в составе AFC имеются средства интеграции двух систем. Компоненты AFC UI, обработанные соответствующим адаптером AWT, могут добавляться к контейнеру AWT. Например, для того чтобы добавить UIButton к классу Panel AWT, потребуется адаптер AwtUIButton. В свою очередь компоненты AWT, помещенные в контейнер AFC UIAwtHost, нормально работают в любых приложениях AFC.

Компоненты JFC Swing, созданные на базе классов AWT, представляют собой естественное расширение AWT и могут использоваться совместно другими компонентами AWT в том же самом контейнере. Но при этом необходимо учитывать один момент. Поскольку технология базируется на архитектуре AWT Lightweight UI, набор SwingSet наследует все недостатки этой архитектуры: если на экране происходит перекрытие элементов, самые сложные объекты данного уровня должны находиться "наверху" независимо от желаемого порядка обновления экрана. Однако этот недостаток не связан с технологией и конкретной реализацией JFC. Тем, кого интересует данный вопрос, рекомендуем более подробно ознакомиться с документацией JDK 1.1 AWT.

Совместимость с JavaBeans

В то время как компоненты JFC Swing полностью совместимы с технологией JavaBeans, существующие на сегодняшний день классы AFC UI пока не могут этим похвастаться. В версии 1.1 AFC появилось средство SimpleBeanInfo, реализующее адаптеры классов AWT. Данные адаптеры используют в качестве базового класса AWT Panel и обеспечивают совместимость с компонентами Beans. Возникает вопрос, можно ли применять адаптеры AWT в качестве объектов Beans, обеспечивающих пользователю доступ ко всем компонентам AFC UI? По умолчанию компоненты AFC не позволяют создавать JAR-файл. Чтобы убедиться в совместимости классов с компонентами JavaBeans, мы попытались объединить соответствующие компоненты AFC в JAR-файл, поддерживаемый JDK 1.1, и загрузить файл в среду BeanBox пакета Beans Developer Kit (BDK), разработанного компанией JavaSoft. При использовании компонентов AFC в некоторых случаях возникали исключительные ситуации. В ходе аналогичного тестирования с пакетом Symantec Visual Cafe были получены приблизительно такие же результаты. На основании этого можно сделать вывод, что AFC не обеспечивает полной совместимости с JavaBeans.

Переход от существующих приложений AWT и IFC к новым технологиям

От AWT к AFC

Переход от приложений AWT к AFC должен пройти относительно безболезненно, потому что модель AFC очень напоминает модель AWT. Простейшим способом является приведение имен классов управляющих элементов AWT к виду UI<имя-класса>, а имен графических классов - к виду Fx<имя-класса>. Например, классы List и BorderLayout должны быть заменены на UIList и UIBorderLayout. Класс Graphics необходимо переименовать в FxGraphics. Поскольку интерфейс прикладных программ AFC в основном похож на API AWT, большая часть кода AWT скорее всего будет компилироваться и выполняться правильно, хотя конструкции большинства управляющих элементов AFC отличаются от соответствующих конструкций AWT и должны быть правильно настроены. Средство Awt2afc, входящее в состав Microsoft Java SDK 2.0, упрощает процесс преобразования, вставляя необходимые комментарии и указания в исходный код AWT. Однако для окончательного преобразования кода по-прежнему без модификации вручную не обойтись.

От AWT к JFC

JFC является надмножеством AWT, поэтому переход от AWT не вызывает затруднений и позволяет приложениям AWT использовать модель событий JDK AWT 1.1. Добавив к именам классов управляющих элементов префикс "J", вы превратите программу AWT в приложение JFC Swing. Управляющие классы AWT будут нормально взаимодействовать с классами JFC. Для адаптации кода обработки событий к модели EventListener могут потребоваться некоторые незначительные изменения. Однако если переносимое приложение было написано с использованием модели событий JDK AWT 1.0, обойтись без хирургического вмешательства не удастся. Придется удалять код обработки событий и заменять его на интерфейс слушателя. Хотя отделение кода управления событиями от кода UI и нельзя назвать простой процедурой, она может оказаться весьма полезной и в значительной степени облегчить поддержку и дальнейшую модернизацию.

Помимо изменений имен классов и модели событий придется вносить некоторые модификации для перехода к архитектуре MVC.

От IFC к JFC

Библиотеку Internet Foundation Classes (IFC), разработанную компанией Netscape, многие называют предшественницей JFC. Предварительные варианты JFC непрерывно совершенствуются, и в очередной версии JFC Swing 0.7 можно обнаружить немалое сходство с IFC. Хотя отдельные важные компоненты IFC полностью перенесены в JFC, переход от IFC к JFC предполагает не только изменение имен классов в исходном коде, но и значительно более глубокую реструктуризацию приложения. Компании JavaSoft и Netscape создали специальные средства, помогающие разработчику осуществить переход от технологии IFC к JFC, но на настоящий момент мы не имеем достоверной информации о возможностях и характеристиках данных средств. Исходя из своего опыта, можем с уверенностью заявить, что практическая реализация процедуры автоматического преобразования исходного кода IFC к формату JFC - это очень сложная задача. Скорее всего разработчики все равно будут поставлены перед необходимостью ручной модификации или даже полного переписывания исходного кода IFC.

Переносимость и поддержка браузеров

Поскольку и библиотека JFC, и AFC написаны на "чистом" Java, теоретически они могут выполняться на любой виртуальной машине Java (JVM) и на любой платформе. Наиболее распространенные браузеры и виртуальные машины, поддерживающие JFC и AFC, представлены в таблице.

Дополнительные возможности

Опыт работы с библиотекой AWT показал, что ее возможностей явно недостаточно для получения полноценных визуальных эффектов. В состав библиотеки AFC включено большое количество классов, имена которых начинаются с префикса "Fx". Эти классы обеспечивают дополнительную поддержку работы со шрифтами и цветом, улучшенную обработку текста и расширенный прикладной программный интерфейс для графических примитивов. Некоторые компоненты AFC реализуют дополнительные функции. Среди них можно выделить вращение текста, создание фона на основе текстур и обработку сложных графических объектов. Двумерный прикладной программный интерфейс JFC позволяет создавать мощные, гибкие и завершенные конструкции, поддерживающие управление шрифтами и цветом, печать, вывод различных изображений, обработку текста, преобразования в пространстве и другие возможности, отличающиеся широтой и глубиной. Полнофункциональные средства работы с двумерной графикой и программными изображениями, реализованные в API JFC, значительно превосходят конструкции Microsoft Fx. Функции двумерной графики, входящие в состав API хорошо взаимодействуют с конструкциями Swing и UI. При этом компоненты Swing не связаны прямой зависимостью с API, но могут значительно расширить визуальные возможности прикладного программного интерфейса. Первая реализация Swing базировалась на поддержке графики AWT, а будущие версии будут использовать все возможности работы с двумерной графикой, встроенные в язык Java. С другой стороны классы Microsoft Fx являются ключевыми элементами библиотеки AFC. Во многих случаях классы и интерфейсы Fx напрямую используются не только компонентами AFC, но и кодом приложения AFC.

Библиотека AFC не поддерживает технологию drag-and-drop. Хотя в одном из примеров, предлагаемых Microsoft, и демонстрировались возможности drag-and-drop, изучив код, мы пришли к выводу, что данные функции встроены непосредственно в платформу Windows. В этом отношении пакет JFC явно выделяется в лучшую сторону. В нем реализована не только платформо-независимая поддержка технологии drag-and-drop для клиентов Java GUI, но и возможности интеграции со средствами drag-and-drop, разработанными для конкретной платформы. Это позволяет любым клиентам Java использовать в своих приложениях все преимущества технологии drag-and-drop.

Как в AFC, так и в JFC Swing встроены средства "дополнительного доступа", позволяющие клиентам, которые не имеют возможности работать с компонентами GUI, воспользоваться другими технологиями.

Простота освоения и использования

Как уже говорилось выше, JFC является расширением библиотеки классов AWT, входящей в состав пакета JDK 1.1, и каждый компонент JFC можно считать подклассом соответствующего класса AWT. В отличие от этого базовый класс UIComponent библиотеки Microsoft AFC является прямым наследником java.lang.Object, а иерархия классов AFC никак не связана с иерархией AWT. Но как ни странно, во внутренней реализации AFC и AWT имеется немало общего. Многие особенности архитектуры AFC унаследованы от AWT. Любой специалист, знакомый с концепцией AWT, сумеет быстро и без особых усилий уяснить концепцию AFC.

С другой стороны библиотека JFC позволяет создавать значительно более сложные конструкции. Архитектура MVC и возможности встраивания дополнительных модулей выводят JFC на принципиально иной качественный уровень:

Короче говоря, прежде чем начать эффективно использовать мощь JFC, программисту помимо AWT потребуется изучить следующие средства:

Кроме того, разработчик, желающий самостоятельно создавать новые компоненты, которые расширяли бы возможности имеющихся классов JFC, должен хорошо разбираться в следующих вопросах:

Чтобы эффективно применять AFC, разработчик должен хорошо знать теоретические основы JDK AWT. Создателю компонентов AFC помимо этого необходимо разбираться во внутренней структуре AFC, а также в технологии работы с двумерной графикой. Прикладной программный интерфейс AFC вполне согласуется со стилем AWT и интуитивно понятен любому человеку, знакомому с этой библиотекой.

Пакет AFC был разработан для замены AWT. Несмотря на то, что архитектура этих двух продуктов принципиально различна и несовместима, набор API AFC очень похож на своего предшественника. Таким образом, программист, работающий с библиотекой AWT, способен освоить его в кратчайшие сроки. Библиотека классов JFC является расширением AWT и наследует ее иерархию. Программисту, желающему использовать всю мощь классов JFC, придется в течение длительного времени изучать сложные конструкции данной библиотеки. Мы полагаем, что пакет AFC позволит разработчику приложений на базе AWT наиболее эффективно применить полученные знания, в то время как для освоения JFC опыт, приобретенный в ходе работы с AWT, уже не столь важен. Дополнительные временные затраты станут своеобразной платой за преимущества, которые дает архитектура MVC.

Заключение

Библиотека Microsoft AFC проста в освоении и использовании. Вероятно, перенос приложений, созданных на основе GUI JDK 1.0, на платформу JDK 1.1 при помощи AFC не потребует значительных усилий. Однако необходимо учитывать, что модель событий AFC является устаревшей и неэффективной. Компоненты, разработанные на базе библиотеки AFC, могут оказаться несовместимыми с технологией Beans. В то же время AFC тесно связана с такими продуктами, как Microsoft Internet Explorer и SDK, хотя ее можно использовать и в качестве автономной библиотеки классов. Пакет JFC полностью совместим с компонентами Beans и построен на базе эффективной модели событий, позволяющей значительно повысить производительность. Перенос существующих приложений, созданных на основе классов AWT и модели делегирования событий JDK 1.1, на платформу JFC не вызывает никаких затруднений. Однако использование основных преимуществ JFC потребует структурных изменений кода приложения. Кроме того, изучение конструкций JFC само по себе является нелегкой задачей.

Как вы уже могли заметить, оба средства разработки имеют свои достоинства и недостатки. Если вы хотите улучшать приложение при помощи дополнительных модулей или разрабатывать эффективные объектно-ориентированные программы и вам нужна гибкость и масштабируемость архитектуры MVC, то нет причин для колебаний. Очевидным выбором является JFC, а затраты на освоение этой библиотеки окупятся сторицей. Если же от вас требуется быстро разработать небольшое и не слишком сложное приложение, мы рекомендовали бы обратить внимание на AFC.

Как выполнять приложения Microsoft AFC с использованием пакета Sun JDK 1.1

По умолчанию библиотека классов Application Foundation Class (AFC) 1.1, входящая в состав пакета Microsoft SDK for Java 2.0, функционирует только под управлением виртуальной машины Java, поставляемой вместе с SDK 2.0. Однако, изменив некоторые настройки AFC, несложно адаптировать ее к работе с JDK 1.1. Все примеры программ из состава пакета Microsoft SDK for Java 2.0 успешно выполнялись в среде JavaSoft JDK 1.1.5 под управлением операционной системы Windows NT 4.0. Для проведения адаптации необходимо выполнить следующие действия:

1. Установите пакет Microsoft SDK for Java 2.0.
2. Найдите файл classes.zip (его размер составляет 7,5 Мбайт), входящий в состав пакета MS SDK for Java 2.0, и распакуйте его содержимое в отдельном каталоге (например, в каталоге C:\afc). Мы обнаружили копию файла classes.zip в каталоге c:\WINNT\Java\Classes.
3. Удалите файлы FxMSVM.class и FxSMVM10.class из каталога com\ms\fx.
4. Создайте JAR-файл для библиотек ui, fx и util. Для этого введите команду: C:\afc> jar cf afc.jar com\ms\ui\* com\ms\fx\* com\ms\util\*
5. Укажите путь к файлу afc.jar. C:\afc> set CLASSPATH=C:\afc\afc.jar;%CLASSPATH%
6. Выйдите в корневой каталог пакета Microsoft SDK for Java. После этого перейдите в каталог samples\afc\statics\classes. Запустите на выполнение пример программы с помощью команды java JDK 1.1: C:\MS-SDK2.0\samples\afc\statics\classes> java SDKSample

Выполнение программы SDKSample ничем не будет отличаться от выполнения по команде jview SDKSample.

Следует заметить, что после данной модификации AFC лишится некоторых возможностей, непосредственно связанных с платформой Windows и/или Microsoft JVM, например, доступа к локальным шрифтам.

Источники информации