В прошлом месяце в JavaWorld были опубликованы две статьи, в которых сравнивались Java Foundation Classes (JFC) компании Sun и Application Foundation Classes (AFC) корпорации Microsoft. Авторы данной статьи развивают эту тему и более подробно рассматривают некоторые вопросы: два средства проектирования графического пользовательского интерфейса (GUI) сравниваются с позиций эффективности, гибкости, расширяемости, переносимости, архитектурных особенностей и удобства использования. Анализируются также простота освоения каждого из двух инструментальных средств и возможность переписывания существующих приложений, созданных на базе технологии AWT, с использованием классов JFC или AFC. Кроме того, разъясняется, как можно выполнять приложения AFC с помощью пакета Sun JDK 1.1.

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

В прошлом году гигантские темпы развития библиотек основных классов Java поражали воображение. Роль основных конкурентов пакета Microsoft Application Foundation Classes (AFC) взяли на себя JFC (ставший преемником широко известной библиотеки Abstract Windowing Toolkit, входящей в состав JDK) и разработанный компанией Netscape набор Internet Foundation Classes (IFC). Проект JFC предусматривает создание отдельного набора классов, полностью совместимого с JDK 1.1. Первая его реализация станет частью ядра Java и войдет в состав JDK 1.2. В свою очередь библиотека AFC обеспечивает обратную совместимость с JDK 1.0, прекрасно работает с JDK 1.1, и есть все основания полагать, что этот продукт будет нормально взаимодействовать и с будущими версиями JDK. Мы считаем, что как AFC, так и JFC в настоящее время имеют достаточно устойчивое положение на рынке и выглядят весьма многообещающе.

Основные компоненты AFC и JFC

JFC включает в себя пять составных частей:

  • AWT;
  • Swing (набор средств для создания GUI на базе Java);
  • Java 2D API;
  • Accessibility API;
  • Средства поддержки drag-and-drop.

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

  • UI - эквивалент Swing и AWT из JFC;
  • FX - пакет, обеспечивающий улучшенную поддержку графики, шрифтов и цвета и включающий в себя некоторые вспомогательные классы.

    Заметим, что 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 разрабатывались с целью:

  • "облегчения" (за счет отсутствия peer-компонентов);
  • повышения производительности;
  • обеспечения согласованного внешнего вида на разных платформах;
  • создания расширенного набора элементов GUI с улучшенными возможностями;
  • реализации "чистого" кода Java (за счет отсутствия "родных" библиотек).

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

  • JFC базируется на технологии JDK 1.1 Lightweight UI Framework, позволяющей создавать эффективные элементы, которые легко адаптируются к работе с существующими моделями AWT. Компоненты JFC являются производными от классов AWT. В отличие от этого AFC основывается на собственной оригинальной архитектуре. В данной библиотеке реализована иерархия классов, приблизительно соответствующая иерархии AWT. Компоненты AFC полностью независимы от классов AWT.
  • JFC жестко связана с моделью делегирования событий JDK 1.1. В свою очередь AFC поддерживает модели событий JDK 1.0 и 1.1 на уровне API, однако внутренняя реализация модели событий основана на версии 1.0.
  • JFC поддерживает архитектуру Model-View-Controller (MVC), а также модульный подход к организации взаимодействия с пользователем. Пакет AFC ориентирован на экранный интерфейс Windows и может применяться на самых различных платформах.
    Picture_1
    Рисунок 1.
    Иерархия классов AWT, AFC and 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.

    Picture_2a

    Picture_2b

    Рисунок 2.
    Простое приложение с кнопкой на экранной панели.

    На рисунке проиллюстрирована разница между моделями событий 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 для создания мощного и эффективного пользовательского интерфейса.

    На практике чаще всего разработчики увязывают имеющиеся конструкции 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, добавление сложных элементов к простым зачастую может приводить к неожиданным результатам. Это обусловлено двумя причинами:

  • Во-первых, любой компонент всегда переадресует запрос на обновление экрана своему базовому классу. В свою очередь базовый класс пытается проанализировать среду функционирования компонента и выполняет обработку в зависимости от характера этой среды.
  • Во-вторых, некоторые составные компоненты, такие как Jtree и Jtable не позволяют напрямую добавлять подчиненные элементы, а вместо этого предлагают специальные возможности представления данных (Renderer/Editor). В частности, если вы добавите компонент Jtree к Jbutton, класс Jbutton будет считать, что содержимым объекта является текст или изображение, и не станет выводить дерево на экран. Приведем другой пример. Если вы добавите кнопку в качестве узла дерева, отображаться на экране она будет нормально, но функция, которая должна выполняться при нажатии кнопки, будет потеряна.

    Мы не собираемся подробно обсуждать концепцию средств 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, представлены в таблице.

    Виртуальная машина Java Версия JFC AFC 1.0.2 AFC 1.1
    JDK VM 1.0.2 Нет Да Нет
    1.1.x Да Нет** Да*
    Internet Explorer 3.0.x Да (с ранними версиями Activator) Да Нет
    4.0.x Да Да Да
    Netscape 3.0.x Да (с будущими версиями Activator) Да Нет
    4.0.4 Требуются средства JDK 1.1 Да* Да*
    Примечания:
    * Более подробная информация изложена в разделе "Как выполнять приложения Microsoft AFC с использованием пакета Sun JDK 1.1", находящемся в конце статьи.
    ** Теоретически AFC 1.0.2 обладает обратной совместимостью с версией 1.0 виртуальной машины пакета JDK 1.1. Однако в документации на AFC 1.0.2 ничего не говорится о поддержке JDK 1.1 VM, а наши испытания подтвердили, что AFC 1.0.2 некорректно работает на JDK 1.1.x.

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

    Опыт работы с библиотекой 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 предлагает модель центрированных данных, коренным образом отличающуюся от традиционных средств создания графического интерфейса, с которыми привыкли иметь дело разработчики.
  • В основе JFC лежат совершенно новые технологии (такие, как UIManager, DirtyRegionManager, Renderer, Editor, Tree RowMapper и TreePath). Каждая из них или является уникальной, или встречается крайне редко, поэтому разработчикам требуется немало времени на их освоение.
  • Сложные компоненты (Tree, Table, TextComponent и некоторые другие) являются очень мощным инструментом, но встроить их в приложения непросто. Все они базируются сразу на нескольких классах. В качестве типичного примера можно привести класс Tree, который имеет собственные интерфейсы (MutableTreeNode, RowMapper, TreeCellEditor, TreeCellRenderer, TreeModel, TreeNode, TreeSelectionModel) и классы (DefaultMutableTreeNode, DefaultTreeModel, DefaultTreeSelectionModel и TreePath). В основе некоторых из этих классов и интерфейсов лежат идеи, значение которых не вполне понятно. Для того чтобы разобраться с ними, потребуется тщательное изучение документации и эксперименты с поставляемыми примерами программ. Другие компоненты, такие как Table и Text, также содержат встроенные классы. Прикладной интерфейс каждого из этих компонентов представляет собой небольшую программную конструкцию, с которой разработчик обязан досконально разобраться.

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

  • модель делегирования событий JDK 1.1 AWT;
  • архитектуру Model-View-Controller (MVC);
  • средства Renderer/Editor и способы их использования в составных компонентах, таких как списки, комбинированные списки и деревья;
  • специализированные API, поставляемые с каждым сложным компонентом.

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

  • архитектуре JDK 1.1 AWT Lightweight UI Framework;
  • порядке встраивания дополнительных модулей, предназначенных для усовершенствования графического интерфейса;
  • способах обновления экранного представления (с использованием интерфейсов и классов DirtyRegionManager, RepaintManager и др.);
  • концепции создания двумерной графики.

    Чтобы эффективно применять 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.


    Чион Лиань, Кевин Луо и Тони Жань работают старшими консультантами в компании InkMark, занимающейся разработкой программ на Java и оказанием консультационных услуг. Адреса их электронной почты: chihong.liang@javaworld.com, kevin.luo@javaworld.com и tony.zhang@javaworld.com.

    Как выполнять приложения 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, например, доступа к локальным шрифтам.


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

  • На странице, посвященной AWT, вы сможете найти всю необходимую информацию о библиотеке AWT, входящей в состав пакетов JDK 1.0 и 1.1:
    http://www.javasoft.com/products/jdk/awt/index.html
  • Обзор Java UI. Главы из книги "The Java Tutorial", в которых описывается создание пользовательского интерфейса на базе Java:
    http://www.javasoft.com/docs/books/tutorial/ui/overview/
  • Новые возможности и перспективы AWT 1.1 на странице JDK 1.1 AWT Enhancements:
    http://www.javasoft.com/products/jdk/1.1/docs/guide/awt/designspec/
  • На странице JDK 1.1 AWT Event Model подробно описывается модель событий AWT:
    http://www.javasoft.com/docs/books/tutorial/post1.0/ui/eventmodel.html
  • На странице JDK 1.1 Lightweight UI Framework перечислены основные трудности, которые могут возникнуть при работе с UI, и способы их преодоления:
    http://www.javasoft.com/products/
    jdk/1.1/docs/guide/awt/designspec/lightweights.html
  • Полное руководство по JDK 1.1 AWT, примеры и ссылки на литературу по API AWT 1.1:
    http://www.javasoft.com/products/jdk/1.1/docs/guide/awt/
  • На странице для разработчика приложений с помощью средств Netscape IFC находится введение в библиотеку IFC, документация, примеры программ и т.д.:
    http://developer.netscape.com/library/ifc/index.html
  • IFC Developer's Guide - полное руководство разработчику программ на базе средств IFC:
    http://developer.netscape.com/library/ifc/
    documentation/endium/developerguide/index.html
  • На странице Microsoft AFC можно найти обзор библиотеки AFC, примеры программ и другую полезную информацию:
    http://www.microsoft.com/java/resource/afc.htm;
  • Страница Microsoft SDKJ 2.0 AFC. Введение, статьи, документация на API и примеры программ для версии SDKJ 2.0:
    http://www.microsoft.com/java/sdk/20/afc/default.htm
  • На странице AFC for JDK 1.0.2 находится введение в AFC 1.0.2 и описываются основные отличия этой библиотеки от версии AFC 1.1:
    http://www.microsoft.com/java/afc/11102tip.htm
  • Различия между классами AFC, совместимыми с JDK 1.0.2, и классами, предназначенными для работы с JDK 1.1:
    http://www.microsoft.com/java/afc/10211diffs.htm
  • На странице JavaSoft JFC приводится описание JFC и примеры использования классов данной библиотеки:
    http://www.javasoft.com/products/jfc/index.html;
  • Swing Connection - новый Web-узел компании JavaSoft, содержащий последнюю информацию о средстве JFC Swing:
    http://java.sun.com/products/jfc/swingdoc-current/in_this_issue.html;
  • Ответы компании JavaSoft на вопросы, касающиеся JFC:
    http://www.javasoft.com/products/jfc/faq.html
  • Раздел книги "The Java Tutorial", посвященный средству JFC Swing:
    http://java.sun.com/docs/books/tutorial/post1.0/ui/swing.html