Компания Sun получила достаточную поддержку, чтобы стать официальным уполномоченным по подготовке материалов по Java для стандартизации в ISO. По мере того как начинает рассеиваться туман политических интриг, возникает вопрос: во что выльется стандартизация для разработчиков Java? В статье анализируются различные компоненты Java, которые следует предложить к стандартизации в первую очередь, а также затрагивается вопрос о том, как Sun и Microsoft будут использовать последние разработки в области Java для достижения своих целей.

Путь к стандартизации долог и извилист. Могут пройти годы, прежде чем язык будет утвержден организацией по стандартам (C++ только сейчас получает окончательное одобрение). И часто спецификация, переданная на утверждение в качестве стандарта, разительно отличается от той, которая принимается как окончательный вариант. Иногда кажется, что добиться стандартизации какой-то технологии - выше человеческих сил.

С другой стороны, реальные возможности владельцев лицензий, игроков рынка и представителей бизнеса могут так и остаться невостребованными, если предлагаемое решение не будет создано с учетом стандартизованных технологий. Многие государственные организации по договору требуют от производителей программного обеспечения придерживаться стандартизованных технологий. Точно так же предприятия предпочитают инвестировать в технологию, подтвержденную солидными томами с описанием стандартов. Разработчики желают работать с хорошо документированными, широко поддерживаемыми технологиями, а стандартизация в той или иной степени гарантирует и то и другое.

Учитывая надежды, возлагаемые на стандартизацию Java, не стоит удивляться, что и Sun (основной персонаж, который стремится получить преимущества от стандартизации всей платформы Java), и Microsoft (самая крупная структура, которая может от этого пострадать) тратят огромные силы на пропаганду своих взглядов.

По иронии судьбы Sun и Microsoft, кажется, пришли к согласию по ключевому вопросу: утверждение Sun в качестве Publicly Available Specification (PAS) - уполномоченного по подготовке материалов для стандартизации Java - будет способствовать укреплению главенствующего положения Sun в разработке и подготовке спецификации технологии на основе Java. Но представления компаний о сути этого процесса и своей роли в нем существенно разнятся. Sun хочет использовать все возможности, чтобы обеспечить поддержку своей платформы и соответственно своего бизнеса, в то время как Microsoft стремится отделить эту платформу от языка и таким образом защитить свой основной бизнес.

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

Что же скрывается за термином "Java"?

Утверждение "мы должны стандартизовать Java" на самом деле довольно туманно. Что же конкретно должно быть стандартизовано? Если вы слишком серьезно отнесетесь к рассуждениям Sun или Microsoft, то имейте в виду, что ни к чему хорошему это не приведет. С моей точки зрения, существует несколько потенциальных стандартов:

  • язык Java (его грамматическая спецификация, ключевые слова и так далее);
  • спецификация на виртуальную машину;
  • основные платформенные API (в том числе стандарт Java Platform, который каждый знает и любит, плюс EmbeddedJava, PersonalJava и т.д.);
  • расширенные API (дополнительные API, такие как стандарт Java Media Framework, расширение Java Servlet API, или дополнительные расширения, к примеру Java3D API).

    Замечание. Мы можем в этом списке указать еще одну спецификацию - на байт-код Java. Байт-код не зависит от языка Java (фактически существуют исследовательские компиляторы, которые преобразуют программы, написанные на других языках, в байт-код Java), но он связан с виртуальной машиной. Однако поскольку процессоры с функциями MMX могут обрабатывать команды x86 и MMX, теоретически возможно создать виртуальную машину, которая поддерживает байт-коды Java, а также какой-нибудь другой байт-код. В качестве базового набора команд для всех существующих коммерческих виртуальных машин Java используется байт-код Java. На самом деле он тесно связан со спецификацией виртуальной машины. Поэтому я не провожу различий между потенциальной спецификацией на байт-код Java и предлагаемой спецификацией на виртуальную машину (чего не делает и Sun).

    Sun заинтересована в том, чтобы все четыре отдельных (или ортогональных) компонента рассматривались как единая технология. Когда представители Sun говорят "Java", они имеют в виду все четыре компонента. Точно так же можно сказать: то, что в Sun называют Java Platform, или Java Application Environment, представляет собой комбинацию языка, виртуальной машины и API. До тех пор, пока другие согласны с этим определением Java и Java Platform и готовы утвердить Sun в качестве Java PAS, компания сохранит за собой контроль над всем, что носит название Java. Утверждение Sun в качестве PAS показывает, в частности, что ISO решила предоставить Sun право определять, что является, а что не является частью полного Java.

    Заметьте, что сама по себе торговая марка Java - это основная точка опоры Sun, поскольку укрепляет ее стратегию в отношении Java. Контроль над торговой маркой дает Sun единственную возможность объединить все под лозунгом Java. Неудивительно, что Sun была столь непреклонна и не уступила ISO контроль над торговой маркой. Если бы она пошла на это, пусть даже в отношении спецификации на язык и виртуальную машину, любой производитель мог бы реализовать эти два компонента, заявить о полном соответствии стандарту Java и затем создать свои собственные библиотеки на их основе, дробя платформу и ослабляя позицию Sun. Таким образом, Sun придерживается стратегии "все или ничего".

    Именно эту целостную технологию Java Microsoft активно стремится разделить на части. Если мир признает спецификации языка и виртуальной машины достойными стандартизации, а базовые и расширенные API - нет или если торговая марка Java будет присвоена одному или нескольким компонентам, а не Java в целом, то Microsoft сможет предложить независимый продукт, поддерживающий Java Platform API компании JavaSoft. Такая тактика позволяет Microsoft по-прежнему пользоваться языком Java, расширяя при этом Java Platform так, как ей выгодно. Фактически именно это Microsoft делала и делает, невзирая на ISO и процесс стандартизации.

    Обе компании, и Microsoft и Sun, понимают, что основа платформы - это не язык и виртуальная машина, а базовый набор API. Таким образом, Sun объединяет API со всеми остальными компонентами Java, а Microsoft, со своей стороны, пытается изолировать от них API.

    Каждому разработчику следует четко понимать разницу между позицией Sun и Microsoft и видеть преследуемые ими цели.

    Что же будет стандартизовано и когда?

    Согласно последним отчетам, касающимся утверждения Sun в качестве уполномоченного по подготовке материалов для стандартизации Java, компания планирует в первую очередь представить на утверждение стандарта язык Java, виртуальную машину и некоторые основные API. Причем прецедент уже имеется. Сначала были стандартизованы языки C и C++ и базовые библиотеки, а затем в качестве стандарта утверждены более совершенные библиотеки и поддержка новых возможностей. В самом деле C++ Standard Template Library только недавно была ратифицирована как компонент стандарта, то есть это произошло спустя несколько лет после утверждения основных составляющих языка.

    Это вполне согласуется с философией и целями бизнеса, описанными выше. Если будет создан прецедент утверждения в качестве стандарта языка, виртуальной машины и API, Microsoft тут же потеряет возможность изолировать Java Platform.

    Конечно, Microsoft по мере сил противостоит Sun. И это естественно. У нее нет выбора. Стандарт Java Platform, официально одобренный ISO и получивший поддержку сотен или даже тысяч производителей во всем мире, - это упреждающий удар по Win32 API и платформе Windows. Это даже не стрелковое оружие, здесь речь идет о широкомасштабной ядерной бомбардировке! Это - война.

    Так что же лучше для разработчиков?

    По-моему, планы JavaSoft в наибольшей степени отвечают интересам разработчиков и владельцев лицензий. Язык в достаточной степени развит и должен быть стандартизован сразу после того, как Sun сможет передать спецификации на ратификацию в JTC1. Достаточно совершенна и технология виртуальной машины. Единственный момент - возможно, стоит дождаться создания некоторых технологий JIT-компиляции и "адаптивной оптимизации" (используемых в новой виртуальной машине HotSpot, разрабатываемой компанией JavaSoft), чтобы довести все до ума. Но, даже признавая справедливость этих суждений, можно уверенно говорить о том, что спецификация почти готова к стандартизации.

    Возможность реальной переносимости является критически важной для разработчиков Java и сильно зависит от утверждения языка и виртуальной машины в качестве открытых стандартов, поддерживаемых ISO и соответствующими организациями. Руководство Sun учитывает этот факт, понимая, что не добьется многого, если в ближайшие месяцы и годы будет держаться за монопольные права на них.

    В отличие от спецификаций языка и виртуальной машины, спецификации на Java API - даже базовые API (те стандартные API, которые предлагаются компанией JavaSoft с Java Development Kit и базовыми runtime-модулями Java) - пока еще весьма расплывчаты. Версия 1.2 базовой платформы, предлагаемая только в качестве предварительной и не имеющая общедоступной реализации, будет содержать новые API. К ним относятся широко разрекламированные Java Foundation Classes - механизм определения степени доступности расширенных API в данном runtime-модуле Java, их версий, ссылок и так далее. Пройдет год или два, прежде чем стабилизируются базовая платформа и стандарт на расширенные API.

    До того как пройти стандартизацию, эти API должны стать в достаточной степени "зрелым" продуктом. Для этого Sun потребуется сохранить контроль над Java, даже лицензировав торговую марку Java с основными API, одновременно работая над завершением последних. Кроме того, компании необходимо найти возможность поддержать использование стандарта и дополнительных API-расширений, а также механизм для переноса расширенных API в Core Platform. Это необходимо сделать, дабы обеспечить поддержку расширений для разработчиков и стандартного способа работы с расширениями.

    Заключение

    Пока удается отсрочить отделение Java Platform API, статус Sun как уполномоченного по подготовке материалов для стандартизации всех компонентов Java будет устраивать пользователей. Если до утверждения стандартов кто-то спросит ваше мнение о необходимости стандартизации Java, в ответ вам следует поинтересоваться: "А о каком из его компонентов идет речь?"

    Билл Дей (Bill Day) - инженер по программному обеспечению компании Silicon Graphics Computer Systems. Он работал над Cosmo Code Java IDE в SGI, создавал тестовый комплект для реализации Cosmo Motion Java Media Framework. Сейчас является ведущим инженером клиент-серверного проекта на основе Java в SGI. Он также является автором книги по Java Media, написанной по заказу O'Reilly & Associates. С ним можно связаться по адресу bill.day@javaworld.com.