Как избежать ловушек нестандартного SDK for Java

AFC

В первой части статьи утверждалось, что применение библиотек Application Foundation Classes (AFC), входящих в состав Internet Explorer 4.0 (IE4) и Microsoft SDK for Java версии 2.0, позволяет создавать Java-приложения для Java-сред, разработанных любыми другими фирмами. Все, что нужно было сделать корпорации Microsoft, - разрешить доступ к AFC, минуя разработанную ею JVM. Уже после выхода статьи стало известно, что корпорация не намерена в обозримом будущем поставлять версию классов AFC для IE4, написанную на чистом Java. Тем не менее такая версия классов AFC готовится для Java 1.0.2. Как только это будет сделано, разработчики смогут создавать с помощью AFC решения, способные работать с различными браузерами. Однако API-интерфейсы этих двух версий будут отличаться друг от друга, поскольку в той версии, которая поставляется с IE4 и SDK, поддерживаются модели событий как Java 1.1, так и Java 1.0. Есть основания полагать, что, возможно, появятся решения, которые будут работать с обеими версиями AFC, подобно тому как, скажем, создаются апплеты Java 1.0, выполняющиеся и в среде Java 1.1. Все же до выхода версии AFC для Java 1.0.2 об этом говорить не стоит.

Кроме того, после того как вышла статья, Microsoft выпустила предварительные версии IE4 для платформ Macintosh и Solaris. Как утверждает представитель корпорации Чарльз Фитцджеральд, библиотека AFC, поставляемая с этими двумя версиями браузера, совместима с AFC, входящей в состав IE4 для Windows. Если эти версии AFC действительно совместимы, то появляется возможность создавать на их основе решения, работающие с различными операционными системами, но не с виртуальными машинами Java. (Скоро должны выйти версии IE4 для HP-UX и AIX.)

Стоит упомянуть еще одно обстоятельство. Классы AFC не распространяются самостоятельно, поэтому их нельзя напрямую использовать как компоненты JavaBeans в инструментальных средствах, совместимых с JavaBeans. Их можно применять на уровне исходного кода и оформлять в виде самостоятельных компонентов, но Microsoft предпочла пока не создавать из AFC компоненты beans.

Изменения класса Locale

В первой статье говорилось о 50 дополнительных переменных типа public класса Locale, а также о дополнительных вспомогательных файлах в пакете java.text.resource. В то время как дополнительные переменные класса Locale являются отличительной особенностью библиотек классов Microsoft, вспомогательные классы Java в объектах Locale не характерны для сред Microsoft. Это означает, что в различных классах Locale можно по-прежнему использовать вспомогательные классы форматирования дат и текстов. Однако нельзя работать с характерными для Microsoft константами. То есть, к примеру, вместо того, чтобы использовать характерную для сред Microsoft константу Locale.FINNISH, придется создавать новый объект Locale с новыми Locale ("fi", "FI") или новым Locale ("fi", "").

RMI

Microsoft предлагает классы RMI компании Sun, которые можно использовать с виртуальной машиной Java. Фактически этот механизм был реализован в августе, но отыскать его было довольно трудно; для этого требовалось выполнять поиск файла rmi.zip. Сейчас этот файл можно найти по адресу ftp://ftp.microsoft.com/developr/msdn/unsup-ed/rmi.zip. Однако поскольку корпорация не предоставляет для RMI никакой поддержки, для использования этих классов с IE4 придется устанавливать их локально. Если для работы апплета требуются классы RMI, он не сможет загрузить их через Internet. Другими словами, классы RMI должны быть получены из источника, заслуживающего доверия (то есть загружены локально).

Различия в поведении объектов

Многие читатели указывали на особенности поведения, которые отличают реализацию Java компании Microsoft. Некоторые даже создавали Web-страницы, чтобы подкрепить свои слова конкретными примерами. Удивительно, что после представленного в статье предварительного анализа интерфейсов API пользователи начали сталкиваться с дополнительными трудностями при использовании классов Java компании Microsoft. Разработчикам следует знать о таких вещах, дабы всячески обходить их. Представители Microsoft заявили, что некоторые различия уже устранены компанией. Но исправленный вариант JVM пока еще не получил достаточного распространения, поэтому лучше знать об этих проблемах, чтобы не тратить усилия на их преодоление.

Ненадежные апплеты и отображение меню в кадрах

Первая проблема связана с выдачей меню в кадрах (frames), открываемых "ненадежными" апплетами. Ошибку можно увидеть на узле http://www.sc-systems.com/public/misc/IE4MenuBug/. Похоже, предупреждающее сообщение ненадежного апплета занимает место, которое необходимо кадру для выдачи MenuBar в IE4, тогда как в браузерах Netscape и Internet Explorer 3.0 оно отображается правильно. Хотя приведенный пример и показывает, каким образом может произойти сбой IE4, средства, которые используются для задания размеров и отображения кадра, не являются традиционными. Большинство программистов смогут избежать этой проблемы, если используют для отображения кадра методы setSize() и setVisible(). Сложности возникнут у разработчиков, которым приходится часто вызывать методы addNotify(), setSize(), а затем setVisible(). Не следует непосредственно вызывать addNotify() для создания peer-компонента. Если программе требуется информация, которую может п редоставить только peer, вместо метода addNotify() вначале создайте новый метод super.addNotify(), после чего используйте полученную с его помощью информацию в переопределенном методе.

Использование IE и proxy-сервера SOCKS

Вторая проблема, обнаруженная читателями, связана с Internet Explorer, сконфигурированным для работы с proxy-сервером SOCKS. Если IE находится в такой конфигурации, Java-приложения, которые начинаются с "jview" (загрузчик командной строки для Java, имеющийся в SDK), будут использовать proxy-сервер. Если у локального брандмауэра нет информации о конфигурации внутренней сети, то при обращении к серверу SOCKS с запросом, адресованным локальному хосту, он станет обрабатывать запрос в общем пространстве имен Internet, что приведет к сбою. Реализованный компанией Microsoft абстрактный класс SocketImpl, имеющий частный (private) класс PlainSocketImpl, просматривает реестр Windows, после чего использует proxy-хост для выбора имени хоста. В случае сбоя простое socket-обращение выдает ошибку SocketException виртуальной машины Java компании Microsoft, хотя нормально работает в средах JDK и Netscape. Более подробное описание этой проблемы можно найти по адресу: http://www.findmail.com/listsaver/advanced-java/4873.html.

С этой ситуацией можно справиться, но при этом необходимо помнить, что она не впервые появилась в последних версиях IE4 и SDK for Java. Обходной маневр предложил Сандар Нарашиман из компании Ascent Technology, которая занимается поставкой распределенных программных решений. Нужно отключить proxy-сервер SOCKS, удалив свойство "socksProxyHost" при помощи следующего кода:

Properties p = System.getProperties();
if (System.getProperty("java.vendor").equals("Microsoft Corp.")) {
 p.remove("socksProxyHost");
}

Различия компиляторов: javac в версии Sun и jvc в версии Microsoft

Третья проблема состоит в разном поведении компиляторов javac из JDK и jvc из SDK. Когда внутренние классы обращаются к частным переменным во внешних классах, компилятор Java компании Sun и компилятор Microsoft обрабатывают эту ситуацию по-разному. Подробно эти различия описаны в документе "Inner Class Access to Private Members of Enclosing Class", который можно найти по адресу http://www.microsoft.com/java/sdk/20/tools/jvcread.htm. При разработке решений, ориентированных на различные реализации Java, следует избегать обращений к частным переменным внешних классов и внутренних классов. Вместо этого надо либо создавать процедуры доступа к переменной, либо заменять ее переменной, являющейся частной для данного пакета. В упомянутом документе содержатся указания на другие связанные с компиляторами проблемы. Например, следует иметь в виду, что:

Проблемы Netscape

В разделе, посвященном Netscape (см. http://javaworld.osp.ru/1997/05/01.html#part_9), я отметил изменения, которые эта компания внесла в библиотеки Java, "ставя заплатку" на Communicator, а также упомянул проблемы, которые в результате могут возникнуть. Автор публикации на эту же тему в WebWeek Дэвид Ф. Карр (см. http://www.webweek.com/1997/10/20/news/19971020-java.html) сообщает, что в Sun знают об этом, и Netscape подписала соглашение, по которому обязуется внести исправления до выпуска окончательной версии. Пока же тем, кто для создания решений с JavaBeans использует средство Visual JavaScript компании Netscape (которое сейчас распространяется в бета-версии), придется обращаться к нестандартным расширениям Java из JavaScript. Это означает, что Visual JavaScript позволяет создавать программы, которые не работают вне Communicator.

Заключение

Выводы, к которым я пришел, анализируя SDK for Java и IE4 компании Microsoft, не отличаются оригинальностью. Последняя версия, подготовленная компанией, пожалуй, только осложнит создание решений, способных работать в различных реализациях Java. До сих пор AFC не является опцией, рассчитанной на разные реализации Java, и не станет таковой, если использовать ее в мире JavaBeans. Тем не менее версия AFC для Java 1.0.2 должна появиться весьма скоро. Кроме того, добавление констант Locale не приведет к тем трудностям, которые ожидались, и классы RMI можно будет использовать в среде Microsoft.

Кроме того, сохраняются особенности поведения реализации Java компании Microsoft, есть в ней и ошибки. Остается надеяться, что большинство из них будет устранено до выхода окончательной версии. Однако уже сейчас идут разговоры о версии 1.1.6 корпорации Sun - правда, ей тоже потребуется время для устранения всех недостатков. В пользу Microsoft говорит то, что эта компания оказалась более отзывчивой к пожеланиям пользователей. Так же, как и JavaSoft, Microsoft предоставила возможность получать некоторые виды поддержки за определенную плату. (Если выясняется, что сбой был вызван ошибкой в коде Microsoft, плата за поддержку не взимается.)

В заключение необходимо добавить, что в конце октября Microsoft выпустила Java-среду, в которой исправлены ошибки, связанные с Menu и Toolkit.beep(). Кроме того, в этой версии реализован метод ByteArrayOutputStream, который не рассматривался в первой статье. В эту версию также добавлен недостающий метод ByteArrayOutputStream, который был пропущен в первом выпуске. Те, кто продолжают испытывать трудности с SDK for Java, могут загрузить новую версию по адресу http://www.microsoft.com/java/vm/vmdownload.htm.