Глядя вперед
Электронная почта принесла достаточно много откликов на нашу статью, в которой мы предлагали покупателям и пользователям более реалистично отнестись к Java и не ждать от этого языка больше того, что он сможет когда-либо предложить. Большинство полученных нами посланий содержало вариации на тему: одна из важнейших особенностей этого языка мобильность, а вы не уделили данному аспекту никакого внимания.
Совсем наоборот. Мы прекрасно понимаем, что способность Java-приложений работать на нескольких платформах ключевая характеристика этого языка, и мы приветствуем ее. Чтобы продолжать развиваться, “Всемирной паутине” Web нужно оставаться платформно-независимой. Если Java-приложениям отводится важная роль в ее развитии, а мы надеемся, что так оно и есть, то они должны быть пригодны для работы на множестве различных типов систем.
Главное отличие между нами и нашими корреспондентами заключается в присущем нам скептицизме. Заявить о том, что язык и библиотеки времени исполнения переносимы, легко. Не составит большого труда даже разработать одну-две начальные версии для нескольких первых платформ. Проблема заключается в поддержке такой мобильности из года в год, от платформы к платформе, в условиях, когда все больше и больше разработчиков будут использовать этот язык.
Эта задача настолько сложна, что успешно решить ее удалось лишь в считанных продуктах.
В далеком прошлом по-настоящему мобильной операционной системой обещала стать Unix с соответствующими интерфейсами API. И что же? Приспосабливая ее к новым платформам, разработчики редко могли удержаться от соблазна пополнить эту ОС новыми функциями. В результате мы имеем целую коллекцию версий Unix, которые очень близки между собой, но несовместимы.
Поклонники Java могут воскликнуть: “Ерунда! Ведь Java это язык и библиотеки времени исполнения, но не операционная система”. Что ж, справедливо.
Помните язык Си? Он начинался как простой язык, разработанный именно для мобильности. Посмотрите, однако, на большинство написанных на Си “мобильных” программ, и вы найдете в них или целые разделы в коде конкретной системы, или системно-зависимые команды условной компиляции, или и то и другое.
Мы можем достичь этого
Все это мы говорим не для того, чтобы доказать, будто мобильность недостижима. Это не так. Не хотим мы сказать и того, что фирма Sun, покупатели, пользователи и разработчики не в силах удержать Java от сползания в болото множества системно-зависимых версий. Вовсе нет.
Sun и все мы вместе с ней должны направить усилия на поддержку тех, кто соблюдает стандарты Java, и на борьбу с попытками ввести в язык функции под конкретную платформу.
Такой подход может оказаться действенным, если Sun по-прежнему будет держать открытыми все аспекты Java. Фирма должна также учитывать вклад других специалистов, работающих над очередными итерациями стандарта. Мы не намерены призывать к созданию комиссий по любым вопросам, однако в отношении Java комиссия по стандартам, наподобие той, что ведет разработку новых стандартов Internet, была бы вполне уместна.
Серьезный недостаток такого подхода заключается в потенциальном замедлении инноваций. Допустим, что некая компания создает удачное, но платформно-зависимое расширение Java. В этом случае разработчикам приложений придется либо отказаться от новых возможностей этого продукта, либо отойти от стандарта с риском оказаться привязанными к одной платформе. Мы бы проголосовали за соблюдение стандарта, но к такому выбору трудно склонить разработчиков приложений, которые упорно ищут инструментарий, помогающий создавать лучшие продукты.
Потенциал языка Java как стандартного инструмента разработки независимых от платформы клиент-серверных приложений огромен, и мы надеемся, что он будет реализован. Однако путь вперед тернист и, похоже, полон соблазнов отойти от стандарта. На преодоление этого искушения нам нужно направить все свои силы.
Марк Л. Ван Нейм, Билл Кэтчингс
