В конечном счете, компания Sun Microsystems сама во всем виновата. Если бы язык Java не был таким привлекательным, он не попал бы в такое неприятное положение. А положение сейчас таково, что язык Java уже почти утратил свое главное достоинство - переносимость. Хотя Sun пытается одновременно и защитить свое детище, и возродить его непорочность - предъявив иск компании Microsoft и выдвинув инициативу 100% Pure Java - выпуск компанией спецификации Java 1.1 увеличил количество имеющихся виртуальных машин Java (JVM) и соответствующих им API-интерфейсов. Проблема усложняется тем, что разработчики, ценящие Java главным образом за его простые для обучения языковые конструкции, солидную поддержку сетевых функций, сильную защиту и встроенные функции надежности (а не за переносимость), легко поддаются искушению покинуть этот прямой, но очень узкий путь в погоне за кросс-платформенной добродетельностью.
Бремя переносимости Java с наибольшей выгодой несут те, кто не знает, какие пользователи посещают их узел, какой бизнес-партнер мог бы получить выгоду от совместного использования их приложений, какие платформы поддерживает компания, с которой они объединяются, или как изменятся их потребности в серверной аппаратуре. Однако с корпоративной точки зрения переносимость остается важной задачей.
НЕЧИСТЫЕ ПОМЫСЛЫ. В связи с судебным иском компании Sun на поверхность выплыло большое количество материалов, толкующих причины стремления корпорации Microsoft разрушить планы Sun в отношении Java, однако в основе этого иска лежало решение Microsoft не включать в браузер Internet Explorer 4.0 и набор Software Development Kit for Java 2.0 поддержку Java Native Interface (JNI) и Remote Method Invocation (RMI), а вместо этого внести в интерфейс Java API собственные дополнения. Интерфейс JNI позволяет разработчику вызывать из Java-программ приложения или библиотеки, написанные на языках С или С++ или языке ассемблера, и упрощает перенос Java-приложений. RMI является аналогом брокеров объектных запросов архитектуры CORBA и модели Distributed Component Object Model.
В пакеты java.*, которые Sun рассматривает как "ядро" любой реализации Java, был включен ряд классов, методов и переменных. Компания Sun считает, что компания Microsoft нарушила условия контракта, поскольку условия лицензионного соглашения с ней и программа Java Compatible требуют полного соответствия базовой спецификации Java - без каких-либо добавлений и/или изъятий. Вместе с тем, Sun не предъявила претензий компании Netscape Communications, продукт которой - Communicator - не обеспечивает поддержки JNI и стандартного пакета безопасности Java, а также содержит нестандартные методы в базовых классах. Мы, однако, не преследуем цели обвинять Microsoft или Netscape; наша задача - оценить любые потери в области переносимости Java.
РАЗДУТЫЙ ДО НЕУЗНАВАЕМОСТИ. Базовые пакеты Java составляют неприкосновенное ядро организма Java и в большой степени определяют возможности его конкретной версии. Число базовых пакетов возросло с восьми (в версии 1.0.2) до 23 (в версии 1.1), а количество классов увеличилось с 211 до 503. Самой последней версией, выпущенной компанией Sun, являлась версия 1.1.4.
Одна из трудных проблем переносимости Java заключается в следующем: API-интерфейсы, которыми пользовался разработчик при создании Java-приложения, должны быть полностью представлены в run-time-варианте API, к которому обращается JVM при выполнении приложений. Иными словами, если у разработчика имеется метод импорта апплета foo(), то при загрузке апплета в JVM будет лучше, если этот метод будет находиться в библиотеке классов браузера. Например, если для создания апплета, обращающегося к классам пакета java.rmi (нового для версии Java 1.1), разработчик использует набор Java Development Kit (JDK) 1.1.4 компании Sun, то пользователь браузера Internet Explorer 4.0 сможет запустить апплет, только инсталлировав сначала этот пакет, поскольку он не включен в состав браузера.
Дело суда решать, нарушает ли это упущение какое-либо соглашение, однако для работы апплета, рассчитанного на доступность RMI, это недопустимо. (К счастью, по иронии судьбы, благодаря тому, что пакеты Java написаны на этом переносимом языке, браузер Internet Explorer может использовать их несмотря на то, что Microsoft не поддерживает RMI). Рассмотрим, однако, с точки зрения просто межплатформенной совместимости различия между версиями Java 1.1 и 1.0 компании Sun, учитывая число используемых в настоящее время браузеров, несовместимых с версией 1.1 (к которым, по мнению Sun, относятся все, за исключением HotJava 1.0 и HotJava 1.1). До тех пор, пока в употреблении еще находится заметное количество платформ предыдущего поколения, разработка продуктов для новых API-интерфейсов всегда будет связана с риском потери какого-то количества пользователей.
В разнообразных дискуссиях о переносимости Java - и о наборе Software Development Kit (SDK) компании Microsoft в частности - высказывается озабоченность тем, что разработчики могут непреднамеренно ввести в свои приложения непереносимый код. Это настоящая проблема для документированных частей измененных классов базового языка Java (к которым относится, например, ряд международных языковых переменных, которые компания Microsoft включила в класс java.util.Locale, и двух методов, которые компания Netscape ввела в класс java.lang.SecurityManager), однако большая часть таких изменений не документирована, и вряд ли ими сможет воспользоваться кто-то, кроме тех, кто самостоятельно пытается что-либо выискать в файле classes.zip с помощью декомпилятора Java. Никто, серьезно относящийся к проблеме переносимости, не будет использовать недокументированные функции.
99,44%-ЧИСТЫЙ JAVA. Язык Java задумывался как мечта программиста. Этот язык обещает освободить разработчиков приложений, в особенности корпоративных, от проблем связанных с необходимостью поддерживать приложения, работающие на различных платформах и использующие API-интерфейсы или методы, свойственные конкретной платформе. Для более надежной реализации кросс-платформенности компания Sun разработала программу сертификации 100% Pure Java (100%-чистый Java), которая стимулирует разработчиков воздерживаться от использования любых интерфейсов Java API, предназначенных только для конкретных платформ. (Компания Sun проводит четкое различие между программами 100% Pure Java и Java Compatible. Программа 100% Pure Java предназначена для апплетов, приложений, сервлетов, компонентов JavaBeans, библиотек и другого кода, написанного на языке Java. Название Java Compatible относится к программе сертификации JVM, компиляторов и комплектов средств разработки; именно она является предметом упомянутого процесса).
К сожалению, из-за различий в реализации между JVM и браузерами, программа 100% Pure Java не является 100%-ой гарантией переносимости (хотя и представляет собой определенную точку отсчета). Документ 100% Pure Java Cookbook компании Sun позволяет понять, что "не все хорошие Java-программы являются чистыми и не все чистые Java-программы являются хорошими". Результаты наших испытаний подтверждают это заявление, поскольку нам легко удавалось создавать как "хорошие и нечистые", так и "чистые, но плохие" апплеты. Мы также обратили внимание на то, что апплет, соответствующий критерию 100% Pure Java, мог бы занять промежуточное место между хорошими и плохими, проявляя себя по-разному на различных платформах.
Следуя спецификации Cookbook, мы создали простой апплет. Чтобы обеспечить одинаковое размещение компонентов на разных платформах, мы использовали менеджер компоновки из набора Abstract Windowing Toolkit. Мы намеренно не хотели устанавливать цвет фона, а решили использовать в качестве фона цвет, установленный на каждой платформе по умолчанию. Мы передали апплет компании KeyLabs для тестирования и сертификации на соответствие 100% Pure Java, и, кроме того, протестировали его сами, чтобы выявить его поведение в различных браузерах на разных платформах. Мы обнаружили существенные различия в поведении апплета.
ЧИСТЫЙ, НО С ОБЪЯСНЕНИЕМ. Когда речь идет о сертификации на соответствие 100% Pure Java, ничто не мешает воспользоваться API-интерфейсами компаний Microsoft или Netscape - однако до тех пор, пока в результирующем коде не появляются методы, дополнительно введенные в базовые API. В них не входят расширенные классы Java, такие, например, как Application Foundation Classes (AFC) компании Microsoft. Sun допускает использование расширенных классов Java, если программа сопровождается пояснением.
Чтобы подтвердить нашу точку зрения относительно дополнительно введенных методов, мы создали апплет, используя методы, включенные компанией Microsoft в базовые интерфейсы Java API. Даже несмотря на то, что описание большинства из этих "скрытых" методов уже опубликовано и мы знали об их наличии, нам пришлось идти своим путем, чтобы ими воспользоваться, поскольку не имелось исходного кода или документации к ним. Мы обратили внимание на то, что некоторые методы из набора SDK for Java компании Microsoft были написаны заново. Например, в классе java.awt.Checkbox из набора JDK 1.1.4 компании Sun отсутствует метод перевода параметра в недействительный (invalidate method), но допускается наследование классом этого метода от своего родительского класса. А в наборе SDK for Java этот метод содержится в классе CheckBox.
Апплет с дополнительно введенными методами невозможно было скомпилировать в JDK 1.1.4, однако нам без проблем удалось скомпилировать его в SDK for Java. Не удивительно, что этот апплет нельзя было запустить ни в одном браузере, кроме Internet Explorer 4.0, но нас удивило то, что его не смог запустить и браузер Internet Explorer для Macintosh. Как оказалось, причина заключалась в том, что в класс Locale мы включили страны и языки, не поддерживаемые Mac OS (компания Microsoft это подтвердила).
ИЗГНАННЫЙ, НО НЕ ЗАБЫТЫЙ. Еще один апплет мы создали с использованием метода, который компания Microsoft удалила из базовых классов Java. Мы не включили интерфейсы, связанные с JNI и RMI, потому что компания Microsoft публично заявила, что их не поддерживает. Хотя Microsoft не поддерживает RMI, она дает возможность загрузить его из Internet по адресу http://www.microsoft.com/java/resource.misc.htm. Для того, чтобы он корректно работал с Internet Explorer, его необходимо установить на локальную машину вместе с другими классами (иными словами, его нельзя загрузить вместе с апплетом). Мы без проблем смогли скомпилировать его в SDK for Java и в JDK 1.1.4. Апплет успешно загрузился в Internet Explorer, Communicator и HotJava, и его внешний вид при этом не отличался. Мы обнаружили, что даже при изъятии компанией Microsoft какого-либо метода из класса, этот метод может быть унаследован из родительского класса.
НА РАСПУТЬЕ. Успех разработки на языке Java может зависеть от того, для кого эта разработка предназначается. Если приложения делаются для сети intranet и все настольные ПК в ней являются Windows-плаформами, работающими с Internet Explorer, то использование классов AFC компании Microsoft из комплекта SDK for Java может дать разработчику кое-какие реальные преимущества. С другой стороны, если для апплетов обязательно необходима переносимость - чтение документа 100% Pure Java Cookbook создает впечатление, что "общим знаменателем" для всех платформ Java компании Sun могла бы стать система без операционной системы или пользовательского интерфейса - разработчикам придется идти очень прямым и узким путем. Однако те, кому необходима широкая переносимость и не требуется чистота, могут занять промежуточное положение, включив в программу условные выражения, проверяющие операционную систему, и оптимизировав ее для наиболее важных платформ.
Разные платформы имеют разные интерфейсы, и многим пользователям удобнее работать с привычными представлениями. В той степени, в какой это верно в некоторых обстоятельствах, мы решили создать апплет с пользовательским интерфейсом базовых платформ, независимо от того, нарушаются ли этим принципы 100% Pure Java Cookbook.
Для сохранения пользовательского интерфейса операционных систем, мы использовали классы Peer и поручали операционной системе выполнение различных задач в зависимости от результата. Хотя мы и знали, что апплет нарушал принципы чистоты Java, мы обнаружили, что он хорошо работал внутри любого браузера на любой платформе из тех, которые мы испытывали.
В целом, несмотря на небольшую разницу во внешнем виде при просмотре разными браузерами и различия в реализации ядра Java, главным препятствием для переносимости, по крайней мере на корпоративном уровне, может оказаться характерная для нынешнего состояния непрямая корреляция между переносимостью, производительностью и прибыльностью.
Мы намеревались оценить общее состояние переносимости Java и определить стоимость поддержки переносимости между двумя основными конкурирующими наборами средств разработки - Java Developer's Kit (JDK) 1.1.4 компании Sun Microsystems и Software Development Kit (SDK) for Java 2.0 компании Microsoft - и имеющимся богатым выбором виртуальных машин Java. Сначала мы пошли легким путем, намеренно вводя непереносимый и потенциально непереносимый код в три апплета, чтобы увидеть, как это повлияет на их работу. Затем мы перешли к более трудной задаче и создали апплет, удовлетворяющий критериям 100% Pure Java, чтобы увидеть, насколько далеко это нас заведет и каких потребует усилий.
Наш апплет был проверен на чистоту компанией KeyLabs - сертификационной организацией, признанной компанией Sun. В результате мы поняли, что ни одно из средств, с которыми мы имели дело - JDK компании Sun, ее программы 100% Pure Java, SDK for Java компании Microsoft и всех интерфейсов API, которые мы могли заполучить - не может обеспечить автоматической переносимости. Но с другой стороны, они и не являются большим препятствием на пути к переносимости, если разработчик этого добивается и хорошо разбирается в вопросе.
С точки зрения ревнителя чистоты, реализация принципов независимости от платформы языка Java и программы 100% Pure Java можно считать достойной и благородной целью, к которой стоит стремиться, хотя бы и в тщетной надежде, что в один прекрасный день какая-либо платформа станет повсеместной. Однако, если спуститься обратно на землю, то поймешь, что разработчикам все же необходимо создавать приложения и делать свою работу, которая, в частности, предполагает выход за пределы ограничений чистоты Java, хотя при этом можно тут же попасться на какой-нибудь случайный крючок "родного" метода или операционной системы. Этот язык еще недостаточно созрел, чтобы можно было исключить связанные с конкретной платформой функции, и если "разброд и шатания" в стане современных браузеров можно считать некоторым показателем, то разработчики еще не скоро будут выступать единым фронтом. И все же, создавая специализированные Java-приложения, чтобы максимально удовлетворить запросы определенной части пользователей или сегмента рынка, приходится наносить серьезный ущерб переносимости, что может привести еще и к тому, что разработчики выберут курс на тот или иной конкретный интерфейс API.
Если переносимость Java и, в какой-то косвенной степени, стандартизация имеют свои преимущества, то они нужны разработчикам и приносят им определенные выгоды, обусловленные тем, что переносимость и стандартизация дают преимущества; эти слова являются полезной тавтологией, которая может и должна иметь право на существование только в том случае, если разработчики хотят следовать определенным принципам переносимости. А иначе - пусть победит производитель браузера, который пользуется наибольшей популярностью.
Хотя законная риторика относительно языка Java имеет целью создание его единой и чистой версии, многие разработчики и пользователи утверждают, что работа с многочисленными версиями Java - дело не новое. Различные реализации виртуальных машин Java, в частности - в браузерах, сделали несовместимость реальным фактом короткой жизни этого языка. Разлад между компаниями Sun и Microsystems выводит ситуацию на официальный уровень и потенциально ее ухудшает.
Некоторые разработчики и независимые производители ПО все еще хотят при написании программ использовать функции для конкретных платформ, однако другие жалуются на то, что "вулканизация" ситуации вокруг Java наносит ущерб их производительности и возможности удовлетворить как можно больше потребителей.
Одна из проблем заключается в том, что разработчикам приходится выбирать между написанием на более высоком уровне абстрагирования с помощью классов Java Foundation Classes (JFC) компании JavaSoft, с помощью классов Application Foundation Classes (AFC) компании Microsoft, или с помощью тех и других. Это обеспечивает разработчикам гарантированную переносимость, однако ухудшает контроль за их собственным кодом.
Многие просто пытаются уйти от этой проблемы, переходя на написание кода для интерфейсов API набора Abstract Windowing Toolkit (AWT) компании JavaSoft. "Нам необходимо иметь возможность пользоваться всеми библиотеками классов Java, поэтому писать для AWT - это не слишком хороший вариант, - объясняет Роджер Белл, президент компании Digital Harbor, разрабатывающей на Java приложения для повышения продуктивности работы. - Так что в настоящее время мы пишем для JFC, потому что у нас не хватает людей, чтобы писать и для AFC, но мы будем делать и это". По словам Белла, компания Digital Harbor не заинтересована в религиозной борьбе между Microsoft и Sun. "Нам хотелось бы писать для JFC, но мы не может отказаться от использования платформы Microsoft", - поясняет он.
Другие разработчики идут на компромиссы между богатством возможностей, предлагаемых полной реализацией Java, и кросс-платформенными возможностями, предлагаемыми написанием очень тонкого клиента. "Что нам удалось, так это сделать клиента чрезвычайно легким благодаря использованию языков Java и Dynamic HTML, - объясняет Майк Эренберг, главный технолог компании Marcam Solutions, производителя средств планирования ресурсов предприятия. - Это означает, что мы до какой-то степени теряем графическое богатство, присущее обеим платформам, однако мы получаем возможность доступа к нашему ПО из любого браузера".
Другие считают, что кросс-платформенная нирвана недостижима и не годится для многих приложений. "В совершенном мире программа 100% Pure Java имеет смысл, но наш мир несовершенен, - считает Рэнди Паркер, президент компании Roving Software. - Нельзя рассчитывать на то, что вы сможете получить полностью кросс-платформенные API для любого ПО. Возьмите, например, журнал регистрации событий сервера, который несомненно имеет характерный для конкретной платформы интерфейс API. . . иногда случается, что вам необходимо взаимодействовать с ОС. Мета-уровень нереалистичен". Со своей стороны, компания Microsoft утверждает, что предоставит средства, которые позволят разработчикам сделать выбор между Java для Windows или кросс-платформенным Java. "Это не обман и не трюк. Разработчики на Java сознают, когда выходят за пределы классов Java, - поясняет Тод Нилсен, генеральный менеджер по связям с разработчиками компании Microsoft. - Мы считаем, что Java как язык хорош, но не верим в Java как в платформу".
По словам Нилсена, отказ компаний Sun и JavaSoft предоставить Microsoft новые версии набора Java Development Kit во время судебного процесса, не помешает компании Microsoft поддерживать необходимую совместимость своих реализаций Java. "Продвигаясь вперед, мы будем поддерживать совместимость языка и байт-кода. Такие средства, как компилятор HotSpot, не повлияют на нас, - утверждает Нилсен. - Если они выпустят еще свои дополнительные библиотеки классов, то у нас не возникнет желания их поддерживать".
Хотя распространенность Windows и модели Component Object Model компании Microsoft говорят в пользу использования платформно-зависимых "крючков" Microsоft, некоторые считают, что в результате разделения платформы Java будут повторены ошибки прошлого. "Я говорю главе Sun Скотту Макнили: Вы должны быть диктатором. В противном случае нам придется покончить с Unix-ификацией Java", - утверждает Джордж Колони, президент компании Forrester Research.
Одна из главных сторонниц Java - президент компании Marimba Ким Полезе - считает, что отрасль будет вынуждена пойти на эффективную стандартизацию Java, несмотря на стычки между Sun и Microsoft. "Я оптимистично настроена относительно Java, поскольку независимым производителям ПО и корпорациям следует подумать об их экономической выживаемости. В сетевой области, кросс-платформенность имеет более важное значение, - заявила Полезе на недавней конференции. - Если вы не имеете возможности развернуть приложения для использования партнерами и внутри предприятия, то вам не повезло. Мне кажется, что со стороны разработчиков будет оказываться определенное давление".
Теперь, когда Sun будет представлять спецификации Java в Международную организацию по стандартизации, или ISO, многие отраслевые аналитики заявляют, что Sun скорее потеряет, чем приобретет, контроль над этой технологией. До сих пор Sun могла разрабатывать свои спецификации за закрытыми дверями.
Однако еще даже до того, как Sun получила от ISO статус "уполномоченного" по Java, отмечает Полезе, значимость Java была намного больше, чем позиции Sun, и этот язык находился вне ее полного контроля. "Java не принадлежит ни одной компании, - считает Полезе. - Двери открыты для всех".
Разработчик, использующий интерфейс Java Native Interface (JNI) (или непосредственно вызывающий тем или иным образом "родные" методы), фактически, отказываются от переносимости. Возможно, это звучит достаточно забавно, поскольку именно этот интерфейс является сейчас яблоком раздора. Как бы то ни было, поддержка родных вызовов может стать практически необходима и может существенно увеличить производительность. С точки зрения переносимости, интерфейс JNI частично смягчает неизбежный порок, обусловленный привлечением родных методов.
Интерфейс JNI разработан с использованием родных методов, содержащихся в наборе Java Development Kit (JDK) 1.0 компании Sun. Из-за ряда недостатков, имевшихся в первой реализации интерфейса, компании Microsoft и Netscape решили создать свои собственные родные протоколы - Raw Native Interface (RNI) и Java Runtime Interface (JRI) соответственно.
JNI, RNI и JRI позволяют приложениям Java взаимодействовать с приложениями и библиотеками, написанными на других языках программирования. Разработчики могут сократить цикл разработки за счет использования старого кода; кроме того, они могут использовать сильные стороны других языков для доступа к специфичным для конкретных платформ функциям и критичным ко времени выполнения процедурам.
Процедура вызова родного метода, которая входила в состав JDK 1.0, оказалась неудачной по двум основным причинам. Во-первых, она не конкретизировала способ размещения объектов в памяти, так что производители выпускали свои виртуальные машины Java (JVM), использующие тот метод, который они считали подходящим. Это приводило к тому, что программистам приходилось заново компилировать библиотеки родных методов на каждой платформе, чтобы предотвратить возможные ошибки.
Во-вторых, неполная "уборка мусора" из памяти приводила к тому, что неиспользуемые объекты удалялись из памяти не всегда, снижая эффективность ее использования. В версии JNI, выпущенной с JDK 1.1, все эти недочеты исправлены.
Использование JNI для реализации родного кода осуществляется просто. Процедуры использования Java-метода и родного метода практически не отличаются, кроме того, что родной метод описывается ключевым словом native (родной) и загружается в Java-приложение перед использованием.
После декларирования родного метода в Java-приложении, файл заголовка (генерируемый с помощью утилиты javah из набора JDK) используется как прототип функции для реализации родного метода. Файл заголовка содержит все необходимые типы данных и параметры, так что разработчику не нужно его изменять. Разработчику больше уже не нужно генерировать пустой файл, как они делали в предыдущей процедуре вызова родного метода. Кроме входных данных, в родном методе обычно декларируются два дополнительных параметра: указатель на среду JNI и ссылочный параметр. Через указатель среды JNI родной метод может получать доступ к объектами и передавать их в Java-приложения. Ссылочный параметр может относиться или к методу класса Java, или к объекту. Для реализации JNI разработчикам необходимо использовать язык С, С++ или ассемблер.
RNI является усовершенствованным вариантом интерфейса JNI из JDK 1.0, повышающим эффективность работы "сборщика мусора". Из-за того, что в SDK for Java 2.0 Microsoft внесла изменения в объектную модель, многие библиотеки DLL интерфейса RNI, разработанные для предыдущих версий Microsoft JVM, во избежание возможной несовместимости нужно будет перекомпилировать.
Реализация родного метода в RNI очень похожа на реализацию в JNI; внутри Java-приложения родной метод декларируется и загружается точно так же. Заголовок для внедрения родного метода необходимо генерировать с помощью утилиты msjavah компании Microsoft. Компания - и это делает ей честь - предоставляет большое число функций родного интерфейса, которые разработчики могут использовать, чтобы легко передавать, захватывать и вызывать объекты и методы из Java-приложений.
Пользуясь RNI (и интерфейсом Java-Component Object Model [COM] компании Microsoft), можно использовать любое средство разработки, поддерживающее создание COM-объектов.
Интерфейс JRI компании Netscape является общим для обеспечиваемых JVM сервисов. Его главной задачей является помощь разработчикам в реализации родных методов, работающих на любой поддерживающей JRI Java-платформе. Чтобы обеспечить максимальную переносимость среди виртуальных машин JVM, интерфейс JRI действует как промежуточное ПО между Java-приложениями и исполняющей системой Java. JRI разбит на компоненты-модули. Его основное преимущество заключается в том, что с его помощью производители JVM могут реализовывать те компоненты JRI, которые представляют интерес для их приложений. Реализация родного метода в JRI подобна его реализации в JNI, однако необходимо генерировать фиктивный файл ("заглушку"), как при работе с JDK 1.0. Компания Netscape изменила также утилиту javah, так что теперь она может генерировать интерфейсы и фиктивный код, работающие с JRI.
Хотя производитель может на законных основаниях ввести в свои JVM комбинацию JNI, RNI и JRI, по-видимому только Netscape готова сделать это, причем, только JRI и JNI. В любом случае, главным препятствием для обеспечения переносимости может оказаться то обстоятельство, что родные приложения или библиотеки не существуют или не могут существовать на той же платформе, что и JVM.
Предварительную версию JNI для Netscape Communicator 4.04 можно загрузить со страницы http://developer.netscape.com/.
Примерно год назад компания Sun Microsystems разработала и анонсировала перспективную программу по обеспечению поддержки Java-разработчиков. Как представляла себе Sun, программа 100% Pure Java должна была предоставить гарантию гладкого исполнения сертифицированных Java-программ на любой совместимой с Java платформе или устройстве. Эта программа является ключевым компонентом более обширного плана, разработанного еще на начальном этапе внедрения языка Java и призванного гарантировать его унифицированность.
Хотя мы полагаем, что эта программа теоретически вполне логична, нам кажется, что в ней есть некоторые ошибки и она вряд ли исполнима на практике. Кроме того, в предлагаемом виде она не дает никаких гарантий гладкого исполнения кода. Не гарантирует также эта программа и создания хороших приложений (и почти не помогает в их создании). Хорошие приложения получаются при разработке и проектировании, исходящих из потребностей пользователей; они представляют собой нечто такое, чего нельзя ни предугадать, ни протестировать с помощью процесса сертификации общего назначения.
Разработчикам нужно иметь в виду, что соответствие критериям 100% Pure Java не является панацеей при разработке кросс-платформенных Java-приложений.
В случаях, когда переносимость играет ограниченную или менее важную роль по сравнению с такими характеристиками, как производительность, то следование программе 100% Pure Java может и не представлять собой лучший путь. Однако, если первостепенной целью является наивысшая степень переносимости ваших программ, то соответствие программе 100% Pure Java и ее поддержка является толковой идеей и выигрышным делом.
В лаборатории нашего Испытательного центра мы решили выяснить, чего стоит написать приложения 100% Pure Java; кроме того, одной из наших целей было получить возможность гордо носить этот логотип. Сам логотип означает, что продукт обеспечивает максимальную переносимость между всеми реализациями Java. Чтобы использовать и выводить на экран этот логотип, мы зарегистрировались и прошли процедуру независимой сертификации в лаборатории KeyLabs - единственной компании, получившей право проведения сертификации.
Процесс тестирования на соответствие 100% Pure Java начинается и оканчивается в сети Internet. Мы посетили узел 100% Pure Java компании Sun (http://java.sun.com/100percent) и загрузили спецификацию 100% Pure Java Cookbook (которая, между прочим, на 100% бесплатна), чтобы изучить стандарты чистоты компании Sun. Cookbook - это "путеводитель разработчика", в котором ясно подчеркнуто различие двух задач - просто написать программу на языке Java и написать переносимую Java-программу.
Чтобы разработать для сертификации 100%-чистую Java-программу, мы создали апплет, не содержащий родных методов, включающий только базовые интерфейсы Java Core API, не использующий недокументированных компонентов реализации Java, не содержащий жестко связанных констант конкретной платформы и привязанный к применимым API-протоколам.
Хотя мы избрали путь сертификации апплета, можно также сертифицировать Java-программу в форме библиотеки классов, сервлета или компонента JavaBeans. Мы решили протестировать апплет потому, что, с одной стороны, им часто пользуются, а с другой - он включает много компонентов, необходимых для правильного исполнения. Java-апплеты размещаются в теле HTML-документа и выводятся на экран через браузер. Платформным интерфейсом для апплета является библиотека Java Core API, виртуальная машина и браузер в том виде, как они абстрагируются классом AppletContext. Если имеются все компоненты, необходимые для надлежащего исполнения апплетов, а также обеспечена идентичность разработки апплетов для неизвестной аудитории сети Internet и их широкое распространение, то основной проблемой становится переносимость.
Нас не слишком удивило, что наш сертифицированный апплет отказался правильно работать на некоторых из выбранных нами конфигурациях. Была ли это ошибка в браузере, проблемы с виртуальными машинами, непереносимый код, имеющий внешний вид "чистого", или апплет проявлял характеристики поведения, не испытанные в процессе сертификации, но наш сертифицированный апплет не всегда исполнялся приемлемым образом.
Лучшее - враг хорошего: написав наш Java-апплет в соответствии с правилами Cookbook, мы продолжали сертификацию своего апплета на соответствие 100% Pure Java. Спецификации Cookbook сопутствует руководство 100% Pure Java Certification Guide (которое тоже можно загрузить бесплатно), призванное помочь разработчикам понять суть процесса сертификации и начать его.
После регистрации и уплаты 1000 долл. (на одну Java-программу) за сертификацию можно загрузить пакет 100% Pure Java Certification. Он содержит все средства и документацию, необходимые для процесса сертификации. После регистрации, процесс сертификации предполагает проведение статической и динамической проверки Java-программы перед предоставлением ее компании KeyLabs. После завершения этой проверки необходимо объединить свою программу с необходимой документацией в пакет верификации и отослать его в KeyLabs. Эта компания отвечает за исполнение процесса верификации, который включает верификационный аудит, верификацию статической проверки, установку и настройку, выполнение динамического теста и составление отчета о сертификации.
Процесс испытаний в своей лаборатории мы начали, пропустив апплет через
программу JavaPureCheck (JPC) 3.0. Ее можно получить бесплатно, не проходя
формальную регистрацию 100% Pure Java. Мы настоятельно рекомендуем использовать
программу JPC для облегчения разработки переносимого кода, даже если вы не
собираетесь проходить сертификацию. Инсталляция JPC была простой, хотя для ее
проведения потребовалась виртуальная машина JVM версии 1.1 или более поздней и
ее библиотеки классов. Средство проверки статического байт-кода JavaPureCheck
проверило наш апплет на проблемы переносимости. JPC проверяет программу в
соответствии с моделью Java
Development Kit (JDK) 1.02 или 1.1.
JPC проверяет программу в два этапа. На первом считываются индивидуальные классы и проверяется чистота всех классов одного за другим. На этом этапе ищутся родные методы и последовательности, специфичные для конкретной платформы. Далее JPC проверяет наличие проблем чистоты, связанных с взаимодействием различных классов в программе. Наш апплет прошел тест JPC блестяще. Мы обнаружили, что если при разработке Java-программы в качестве руководства используется спецификация 100% Pure Java Cookbook, то программа, скорее всего, пройдет проверку JPC.
Вдобавок к апплету, который мы выбрали для прохождения процесса сертификации, мы разработали еще три апплета и запустили JPC с ними. Мы пытались протестировать саму JPC, чтобы посмотреть, насколько хорошо она обращается с Java-программами, при написании которых не использовалась CookBook в качестве руководства.
JPC правильно распознала родной метод компании Microsoft в нашем апплете №2. К сожалению, в том же самом апплете JPC не распознала метод, переписанный из родительского класса, который она проверяла, и правильно пропустила апплет №3. Нас очень удивило, что JPC объявила наш апплет, содержащий Java-код, предназначенный для исполнения на конкретной ОС, чистым. Совершенно ясно, что JPC не является окончательным средством проверки на полную чистоту; скорее она является просто хорошим индикатором чистоты ваших программ. Кроме использования графического интерфейса, программа JPC генерирует файл отчета, который мы передали компании KeyLabs в качестве части нашего пакета верификации.
Когда мы завершили этот этап и прошли статическую часть испытаний, мы создали для своего апплета специальный тестер. Как сказано в руководстве, "назначение тестера - подтвердить, что ваша программа не зависит от особенностей конкретной операционной системы или браузера, и что потенциально нечистые части вашей программы, на которые указывает JavaPureCheck, на самом деле чистые". При помощи JavaSpin мы создали для своего апплета автоматический драйвер. JavaSpin - это средство, разработанное в подразделении SunTest компании Sun для упрощения записи в апплет последовательности действий пользователя, таких как щелчки мышью. Средство JavaSpin создает Java-программу, фиксирующую действия в течение сеанса записи. JavaSpin работает с приложениями, апплетами или компонентами JavaBeans.
Чтобы пройти сертификацию, мы должны были предоставить свидетельства того, что записанные драйверы JavaSpin выполняют весь наш Java-апплет. Программа должна быть "оборудована" так, чтобы собирать информацию о степени покрытия (coverage). Это "оборудование" сообщало нам, какие методы были использованы тестером.
Утилита Pcov измеряет степень покрытия; она собирает информацию из профайла, созданного виртуальной машиной JDK с использованием параметра профайла. Чтобы создать профайл, запускаемый с утилитой Pcov, достаточно просто исполнить записанную Java-программу,.
Когда мы использовали Pcov для измерения степени покрытия, мы обнаружили дефект. Независимо от того, сколько раз мы испытывали свой апплет, Pcov сообщала о нулевом покрытии. Мы обсудили этот момент с компанией Sun и обнаружили ошибку, проявляющуюся при использовании этой утилиты с апплетами, разработанными с применением JDK 1.1.4. Имелись и другие методы оценки степени покрытия, однако поскольку наше время истекало, мы решили сопроводить свой верификационный пакет инструкциями, которые позволили бы компании KeyLabs вручную проводить тестирование на степень покрытия.
Чтобы передать пакет верификации, мы заполнили несколько форм, включающих инструкции по установке, такие как требования к аппаратуре и ПО. Мы также предоставили инструкции по инсталляции и запуску нашего апплета, определили наши сертификационные платформы, а также скопировали все необходимые файлы, такие как Class, Result и AutoRun, в соответствующие каталоги. По завершении, мы заархивировали свой пакет и послали его по электронной почте в компанию KeyLabs. Через два дня она сертифицировала наш апплет как соответствующий требованиям 100% Pure Java.
Самое ценное, что мы вынесли из работы с компанией KeyLabs, не относилось к процессу верификации, который она запускала на наших апплетах. (Как следует из названия, процесс верификации в действительности включает повторный запуск и верификацию на тех же самых тестах, которые мы уже выполняли перед передачей в эту компанию). Более важным для нас оказался отчет KeyLabs, в котором были отмечены некоторые аномалии, выявленные при тестировании нашего апплета в ее лаборатории. Хотя мы столкнулись с таким же поведением и при своем тестировании, информация такого типа может быть неоценимой для разработчика.
Замечания, сделанные компанией KeyLabs, не входят в официальный отчет Certification Acceptance Report. Компания предоставила нам следующую полезную информацию: "В AWT (Abstract Windowing Toolkit) имеется несовместимость между браузером HotJava Browser 1.0 (c JRE1.1.1), работающим под управлением ОС Solaris и Windows 95/NT. А точнее, в Windows VM НЕ видны линейки горизонтальной прокрутки. Однако, средство просмотра апплетов (из JDK1.1.4) не выявило несовместимости между Solaris и Win95/NT. Поскольку это средство просмотра апплетов является фактическим стандартом, то проблема, по-видимому, связана с реализацией браузера HotJava Browser 1.0. Чтобы подтвердить этот вывод, мы провели тестирование с версией 1.1 этого браузера (c JRE 1.1.4) под управлением Solaris и Win95/NT. В этом случае несовместимость не проявлялась. Это указывает на то, что ошибка, вызывающая неправильное поведение AWT при работе с версией 1.0 HotJava, в версии 1.1 исправлена".
Кроме процедур испытания и верификации в компании KeyLabs, мы также провели тестирование нашего сертифицированного апплета в своей лаборатории. Мы тестировали его, используя в целом 10 конфигураций, включая четыре различных операционных системы и три различных браузера.
Несмотря на то, что этот апплет был довольно простым и прошел сертификацию на соответствие критериям 100% Pure Java, его поведение при работе в некоторых конфигурациях в нашей лаборатории было неправильным. Апплет состоял из четырех окон со списками, причем пункты списка можно было перемещать из окна в окно. Кроме того, в него были включены две кнопки "Очистить" (Clear) и "Передать" (Submit), однако они не функционировали.
Полученные нами результаты представляли собой сочетание данных, различающихся по внешнему виду и поведению. На фоне их неоднородности выделялись несколько ярких пятен. Браузер HotJava на всех платформах вел себя по меньшей мере адекватно, не считая различий между версиями HotJava 1.0 и 1.1. HotJava выполнял наш апплет на трех платформах, однако его вид и поведение при работе на ОС Sun Solaris оставляли желать лучшего. Еще одной выигрышной комбинацией было сочетание браузера Internet Explorer с Windows 95 или NT, хотя его версия для компьютеров Macintosh дала разочаровывающие результаты. Например, неработающие линейки вертикальной прокрутки действовали только в качестве разделителей окон списков, и не осуществляли других функций, а щелканье мышью с целью перемещения пунктов по окнам списков также не работало надлежащим образом. В браузере Netscape Communicator на компьютере Macintosh апплет имел вид, подобный тому, что мы получили в Internet Explorer, однако его реакция на щелканье мышью была адекватной. Повозившись изрядно с новыми версиями Communicator, мы нашли, наконец, выигрышную комбинацию, работающую под управлением Win95 и NT. Браузер Explorer показал себя наилучшим образом и под Win95, и под NT. Работой Communicator и HotJava под ОС Solaris мы остались несколько неудовлетворенными. Хотя апплет работал правильно, его общий вид с неровными окнами списков было непривлекательным.
Трудно понять, какой именно компонент повинен во всем этом неправильном поведении, не проведя более глубокий анализ. Мы поняли, что никакой отдельный компонент, действующий "чисто", не может гарантировать гладкое исполнение Java-апплета. Для этого необходимо нечто большее, чем просто соответствие апплетов критерию 100% Pure Java. Неправильные результаты могут быть обусловлены совместной работой всех других компонентов - HTML-документа, браузера, интерфейса Java Core API и виртуальной машины. Те аномалии, которые мы обнаружили во время своего тестирования, не являются результатом нечистоты Java-кода; они свидетельствуют о том, что несколько важных компонентов, необходимых для исполнения апплета, иногда могут работать несогласованно. Для компонента чистота сама по себе является всего лишь необходимым условием, однако его поведение при исполнении определяется именно взаимодействием компонентов. Такие программы сертификации, как 100% Pure Java, которые помогают обеспечить переносимость, гарантируя соответствие отдельных компонентов стандартам переносимости, являются шагом в правильном направлении.
Для создания коммерческих приложений необходимы хорошие средства тестирования, однако современные средства тестирования для Java пока еще пребывают в детском возрасте. Я проанализировал комплект SunTest Suite компании Sun Microsystems - набор коммерческих инструментальных средств для тестирования, работающий на любой Java-совместимой платформе. Хотя эти средства еще не так отшлифованы, как их аналоги для более укоренившихся платформ, они, тем не менее, обладают рядом превосходных функций.
Комплект состоит из трех компонентов. Флагманский продукт JavaStar 1.1.4 представляет собой средство тестирования интерфейса GUI типа "захват-и-воспроизведение", аналогичное пакетам для других платформ, таких как Visual Test компании Rational Software. Компонент JavaScope 1.0 FCS - это средство для проведения анализа степени покрытия (охвата тестирования), которое следит за тем, чтобы тестирование прошли все части приложения. Наконец, JavaSpec 1.01 - новаторское средство тестирования, позволяющее разработчикам испытывать отдельные классы в тысячах, и даже миллионах ситуаций.
Хотя в сопроводительных маркетинговых материалах комплект называется "самым интегрированным продуктом для Java-тестирования", это можно объяснить тем, что в настоящее время он является единственным продуктом на рынке. Это действительно надежные средства, однако фактически интеграция между ними отсутствует; они, в сущности, работают независимо, как отдельные средства. Хотя средства JavaStar и JavaScope можно использовать совместно, ни одно из них не будет знать об одновременной работе другого. Файлы регистрации, конфигурационные файлы и файлы результатов все ведутся этими средствами тестирования отдельно.
Из всех этих средств JavaStar являет наиболее отшлифованным продуктом, снабженным привлекательным и простым в использовании интерфейсом. Я смог написать сценарий тестирования сразу, не обращаясь к документации. Написание сценария оказалось интуитивно понятным и простым. Моя единственная претензия к этому продукту состоит в том, что он несколько медлителен, вероятно потому, что это Java-приложение, которое в свою очередь запускает испытываемый Java-код, так что результирующая производительность от этого страдает. На машине в двумя процессорами Pentium II 300 МГц производительность была превосходной, тогда как на системе с процессором Pentium 120 МГц его работа определенно была замедленной.
Создание сценария с помощью JavaStar сводится, главным образом, к записи нескольких действий, последующей приостановке записи и введению точек синхронизации и верификации. Проверка в точках синхронизации подтверждает готовность приложения к работе, а проверка в точках верификации - корректность состояния приложения. Сначала процесс типа "стой-иди" показался мне обременительным, однако поработав с ним некоторое время, я перестал испытывать трудности.