JFC против AFC: мнения разделились

Разработчики вынуждены решать проблемы, связанные с различиями двух конкурирующих наборов базовых классов Java

Sun, Netscape, IBM и ряд других компаний выпустили набор базовых классов Java под названием JFC (Java Foundation Classes), а Microsoft - AFC (Application Foundation Classes). JFC вскоре станет частью ядра Java. Крупнейший в мире производитель ПО снова окажется "посторонним", пытающимся навязать разработчикам лишние проблемы. В статье проводится подробное сравнение конкурирующих наборов (с обобщением достоинств и недостатков каждого), приводятся советы и мнения опытных разработчиков относительно критериев выбора того или другого.

C выпуском наборов базовых классов Java конфликт между Sun и Microsoft разгорелся с новой силой. Microsoft в настоящее время поставляет предварительную версию AFC. Sun, Netscape и IBM совместными усилиями разработали JFC, общедоступная бета-версия которого должна появиться в самое ближайшее время. С выпуском JDK 1.2 (он намечен на текущий год) JFC станет частью ядра Java. Как только это случится, Microsoft будет обязана начать поставки JFC в составе виртуальной машины Java для Windows. Однако, как и в случае с RMI и JNI, Microsoft заявляет о своем нежелании делать это, поскольку "ее технология лучше".

Утешением для разработчиков может послужить то, что обойти отсутствие набора базовых классов гораздо легче, чем отсутствие ответственного промежуточного ПО. Плохо то, что идея "написано однажды - работает везде" снова терпит поражение, причем не из-за технологических недочетов, а из-за неспособности Sun и Microsoft прийти к соглашению.

Экскурс в недалекое прошлое

В состав первой версии Java входил набор Abstract Windowing Toolkit, или AWT. Некоторое время тому назад даже Microsoft и Netscape сходились во мнении, что AWT является неадекватным. Он отличался низкой производительностью и громоздкой и ограниченной событийной моделью.

Одной из отличительных черт первых выпусков JDK 1.1 был полностью переписанный AWT (включая событийную модель, которая стала принципиально новой). Говорили, что новый AWT стал более высокопроизводительным и гибким. Несмотря на это, Netscape разрабатывала Internet Foundation Classes (IFC), а в январе прошлого года Microsoft объявила о намерении создать AFC.

В марте 1997 г. Microsoft продемонстрировала первый вариант AFC, а в апреле - выпустила предварительную версию для разработчиков. Примерно в то же время на конференции JavaOne компании Sun и Netscape объявили о планах по совместной с IBM и другими разработке набора JFC, в который должна была войти достаточно большая часть IFC.

Microsoft не упустила случая обвинить Sun и Netscape в том, что они договорились о создании JFC, не рассмотрев как следует возможности взять AFC за его основу. Как утверждает Джо Херман, менеджер Microsoft по приложениям и клиентскому ПО для Internet, набор AFC обладает существенным преимуществом перед JFC, поскольку он был выпущен на целых полгода позже.

Sun всегда была готова к совместной работе над Java-технологией с другими компаниями, отвечает Рик Левенсон, директор по разработке из компании JavaSoft. "Если бы лицензионное соглашение, предлагаемое Microsoft, позволяло нам изучить исходный текст AFC, не принося в жертву всей проделанной нами работы, мы, вероятно, смогли бы договориться. Но нынешние условия Microsoft этого не позволяют", - говорит он.

Не просто компоненты пользовательского интерфейса

Одно из заблуждений относительно AFC и JFC состоит в том, что они являются всего лишь наборами элементов для создания интерфейсов. Однако это не совсем так.

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

Кроме того, Microsoft поставляет набор функций для организации распределенных вычислений, названный "AFC Enterprise Libraries". Он представляет собой альтернативу библиотекам Enterprise Java компании Sun, поставляется отдельно от AFC, и в сравнении с JFC не участвует.

Большая часть обзора посвящена анализу и обсуждению Swing - комплекта интерфейсных компонентов JFC. Sun выпустила несколько предварительных версий этого набора классов для разработчиков, и вскоре собирается начать его поставки в качестве дополнения к JDK 1.1.

Второй основной частью JFC является поддержка двумерной графики. Графические функции требуют наличия некоторого количества платформенно-зависимого кода, поэтому библиотека двумерной графики выйдет лишь с появлением JDK 1.2. Его бета-версия появилась в декабре 1997 г., а окончательная должна выйти до конца первой половины текущего года.

Как в AFC, так и в JFC, входит поддержка функий буксировки (drag-and-drop) и доступности для людей с физическими недостатками.

JFC и AFC в сравнении

В атмосфере разногласий между компаниями и растущего беспокойства по поводу возможного замедления развития Java разработчикам остается лишь сравнивать достоинства каждого набора классов. К сожалению (а может, и к счастью), если судить по одному лишь этому узкому критерию, явного победителя нет. "Соответствующие компоненты JFC и AFC весьма схожи, - говорит Билл Лоуб, старший разработчик Stingray Software. - С точки зрения функциональности, очевидные преимущества, способные вывести один из наборов на первое место, просто отсутствуют".

Как в JFC, так и в AFC, присутствуют практически все основные компоненты и функции пользовательских интерфейсов (кнопки-переключатели и выключатели, метки, комбинированные и обычные списки, средства управления текстом и редактирования, меню, окошки помощи по инструментам, прокручивающиеся панели, инструментальные линейки, индикаторы уровня, деревья, панели с закладками и функции буксировка). Оба набора поддерживают (или будут поддерживать) JavaBeans, событийную модель AWT 1.1, печать, цветовую палитру родительской ОС, управление без помощи мыши и функции доступности.

Теперь, когда мы отметили сходство, следует напомнить, что исторические корни AFC и JFC существенно различаются. AFC был создан на основе комплекта Microsoft Foundation Classes (MFC), входившего в состав среды разработки C++. В работе над JFC принимали участие инженеры Netscape; и в его составе использован набор IFC, разработанный этой компанией. Хотя представители противоборствующих сторон и принимали участие в совместных обсуждениях базовых классов, занимавшиеся их реализацией группы разработчиков были изолированы друг от друга.

Следовательно, заметные различия должны быть.

Иная архитектура

Одно из важнейших различий, говорит Эрик Свильденс из Neuron Data, заключается в фундаментальной архитектуре. Хотя и AFC, и JFC обладают "легковесной" архитектурой (т.е. свободной от peer-компонентов) и обе они поддерживают событийную модель с делегированием, архитектура интерфейсной части JFC основана на моделях и представлении (model-view), тогда как центром интерфейсной архитектуры AFC являются компоненты. Коротко говоря, несмотря на то, что оба набора классов содержат практически одни и те же компоненты, использовать JFC на простых проектах - все равно, что забивать микроскопом гвозди, тогда как AFC, в свою очередь, вряд ли годится для создания сложных интерфейсов к приложениям уровня предприятий.

В соответствии с архитектурой "модель-представление", в JFC для отображения, например, списков служит интерфейс прорисовки (renderer), а для манипуляции с ними - интерфейс редактирования (editor). Таким образом, один и тот же компонент может вывести на экран несколько разных элементов, и отображение отделено от модели данных. Список в AFC, напротив, представляет собой простую панель, способную отображать свое содержимое лишь в виде строк, расположенных одна под другой. Контейнеры AFC, как правило, должны резервировать гораздо больше средств управления, чем соответствующие контейнеры JFC.

Таким образом, в целом, API AFC и проще, и меньше. С ростом создаваемого интерфейса, однако, более сложные API JFC, по всей видимости, выиграют у первых по масштабируемости и гибкости. Использование подхода "модель-представление" позволяет с легкостью создавать сложные интерфейсы, в которых объекты UI привязаны к внешним структурам данных. При использовании AFC же разработчик вынужден заботиться о том, чтобы пользовательский интерфейс постоянно приводился в соответствие с внешней моделью данных.

Однако, JFC снабжен простыми интерфейсами для многих из своих классов, что позволяет не отделять модель от отображения при создании того же списка. Тем не менее, разработчикам все равно придется иметь дело с рядом методов, поддерживающих более сложное поведение.

Другие различия

Существует и ряд других отличий JFC (касающихся, в основном, с подмножеством Swing) от UI-компонентов AFC. Наверное, самое важное из них - это обеспечиваемая Swing возможность настройки внешнего вида (look-and-fell) программы. "Если разработчику небезразлично, как выглядит его приложение, и он не хочет, чтобы оно имело интерфейс Windows, то ему больше подойдет JFC", - говорит Лоуб. В JFC встроены два динамически переключаемых внешних вида, соответствующие Windows и Solaris. Их можно расширить или создать новые, собственные. AFC подобной гибкостью не отличается.

Swing снабжен также графическим "отладчиком". Отображение графики на различных платформах происходит по-разному. Графический отладчик замедляет вывод изображений, и разработчик видит, в каком порядке он происходит. Демонстрацию работы отладчика можно найти в наборе Swingset, имеющемся на Web-узле Sun.

Как утверждает Лоуб, JFC отличается от AFC заметно более мощными возможностями управления подокнами (окнами, которые могут находиться внутри основного окна). Их можно располагать в несколько слоев, минимизировать, максимизировать и закрывать.

JFC снабжен также диспетчером макетов, основанным на "пружинах" и "распорках" (springs and struts). Разметив диалог пружинами, можно добиться, чтобы при модификации его размеров пользователем автоматически изменялись расстояния между элементами диалога. Распорки, напротив, позволяют эти расстояния зафиксировать.

Опытные разработчики Windows-приложений, конечно же, заметят, что AFC гораздо более соответствует этой ОС по компонентам и их поведению. В частности, в AFC есть "плавающие" меню и линейки, которые можно заполнять перемещаемыми клавишами и элементами управления (такая линейка находится, например, наверху окна Internet Explorer). При использовании средства выбора объектов (пунктирный прямоугольник переменного размера) текст и изображения "прокручиваются" в любом направлении. Имеется множество готовых диалогов, например, для выбора шрифтов и цвета, вывода сообщений и т.д. Многие их этих диалогов были перенесены из Microsoft Foundation Classes. Кроме того, AFC снабжен средствами создания "мастеров" (wizards), представляющих собой диалоговые окна с закладками и клавишами "next" и "previous", служащие "проводниками" пользователя при выполнении многоэтапного задания.

В JFC есть переставляемые инструментальные линейки, но меню - нет. Впоследствии Sun собирается добавить в JFC большее число готовых диалогов.

Одно из фундаментальных отличий AFC от JFC - поддержка событийной модели AWT из JDK 1.0.2. На короткий срок это может привлечь разработчиков, поскольку многие виртуальные машины Java еще не поддерживают JDK 1.1.

Вопрос чистоты

Отношения Microsoft с сообществом Java весьма неоднозначны. С одной стороны, представители компании подчеркивают, что все компоненты AFC написаны на чистом Java, что гарантирует переносимость кода. С другой стороны, члены высшего руководства Microsoft частенько высмеивают Java, а "независимое" заключение, помещенное на ее Web-узле, гласит, что принцип "написано однажды - работает везде" является невыполнимым.

По словам Хермана, стратегия Microsoft в отношении Java будет развиваться в трех направлениях: выпуск виртуальной машины Java, разработка полезных, платформенно-независимых расширений вроде AFC и выпуск Java-кода, полностью использующего возможности ОС Windows (например, J/Direct). "Мы не используем термин 'Pure Java', - говорит Херман. - Однако платформенно-независимые расширения Microsoft написаны без использования функций, отсутствующих в Java. Как утверждает Херман, Microsoft рассматривает "100% Pure Java" как маркетинговую компанию и уверена, что Sun никогда не позволит сертифицировать важные технологии Microsoft.

Многие разработчики не согласны с такой позицией. "Очевидно, Microsoft пытается найти путь, который помог бы ей столкнуть Java с рельсов, - говорит Стив Адлер, директор компании Triteal. - Вначале Microsoft поддержала и одобрила Java, затем возненавидела его, а сейчас хочет выбрать приглянувшиеся ей компоненты и выкинуть остальное".

Несмотря на наличие большого числа ПК на основе Windows в Triteal, компания старается перевести как можно большее число платформ (в том числе и NC) на единую программную базу. "Вот уже два года, разрабатывая приложения на Java, мы прежде всего рассчитывали именно на то, что они смогут работать на любых платформах. AFC нам не подходит. Для достижения нашей цели необходимы функции, присущие лишь JFC. Мы заключаем партнерские договоры с компаниями, которые выпускают сетевые компьютеры без поддержки AFC", - говорит Адлер.

Сотрудники Triteal протестировали AFC и нашли возможность использования функций Windows интересной. "Но, если вы хотите писать программы для Windows, почему не делать этого на Visual Basic или Visual C++? Если Microsoft не поддержит все спецификации Sun, нам останется лишь надеяться, что виртуальную машину Java для Windows выпустит какая-нибудь другая компания", - говорит Адлер.

"Разработчики ПО для пользователей, работающих только с Windows и Internet Explorer, могут спокойно брать на вооружение AFC, - отмечает Джон Зуковски из MageLange Institute. - Если же вы создаете программы для Internet вообще или для разнородной сети intranet, гораздо безопаснее будет использовать JFC".

Существует некоторое расхождение во мнениях относительно возможности кросс-платформенной разработки с помощью AFC. Зуковски твердо убежден, что AFC не является кросс-платформенным, поскольку он будет работать лишь с виртуальной машиной Java, встроенной в Internet Explorer. Херман подчеркивает, что IE поставляется с Windows- и Macintosh-системами, а вскоре появится его версия и для Unix. Свильденс утверждает, что проблема заключается в инсталляционных скриптах AFC, которые написаны таким образом, чтобы продукт работал только с Internet Explorer. Свильденсу удалось установить AFC вручную и заставить его работать с браузером Netscape, но это оказалось не слишком простым делом.

Споры вокруг AFC и JFC привели в замешательство даже самых опытных разработчиков. Марк Люсьер, старший технический директор Sanga International, протестировал оба набора классов и с энтузиазмом поддержал Pure Java и JFC. Однако, он опасается, что когда выйдет JDK 1.2, а JFC станет частью ядра платформы Java, ее система защиты будет мешать загрузке альтернативных наборов классов.

Как уверяет Левенсон из Sun, выбор базового набора классов апплетом зависит от платформы, на которой он работает. Соответственно, в этом нет никакого нарушения модели защиты Java. Люсьер прав в том, что нарушением будет попытка подмены классов java.*, являющихся основой спецификации Java. Так действовал бы вирус типа "троянский конь".

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

Заключение

Раскол между Microsoft и лагерем Sun-Netscape-IBM наиболее серьезным образом отразится на пользователях Web, являющейся полем борьбы браузеров Netscape Navigator и Internet Explorer.

Несмотря на отсутствие точных данных о количестве пользователей, применяющих виртуальную машину Java, встроенную в браузер (а не предоставленную производителем ОС или промежуточного ПО, поставщиком приложений или системным интегратором), можно предположить, что распределение выглядит следующим образом. Пользователи корпоративных сетей intranet и extranet скорее всего применяют JVM, предоставленную производителем ПО или системным интегратором. Большинство домашних пользователей, студентов, внештатных сотрудников и малых предприятий, по всей видимости, применяют JVM, встроенную в Navigator или Explorer.

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

Дополнительная информация