Ведущий инженер корпорации Sun Microsystems рассказывает о ходе работ по развитию языка Java
Джеймс Гослинг: «Конечно, хотелось бы, чтобы на любой вопрос можно было дать четкий и правильный ответ, но политические игры начинаются всякий раз, когда в комнате собирается больше одного человека.»

Корреспондент электронного журнала JavaWorld Билл Веннерс, сам являющийся активным пользователем языка программирования Java, не в первый раз беседует с Джеймсом Гослингом, одним из ведущих инженеров корпорации Sun Microsystems, создателем Java.

Джеймс, как бы вы оценили итоги своей работы за последний год?

Теперь я гораздо меньше времени провожу в поездках и не планирую пока выступать с публичными «проповедями». Пользователи за последние годы очень сильно изменились. Сегодня мне трудно решиться на выступление перед аудиторией. Я почти полностью переключился на вопросы и ответы, когда люди либо напрямую общаются со мной в режиме диалога, либо заранее оставляют свои записки с вопросами. Прошедший год я провел в лаборатории Sun.

Основное внимание уделялось средствам разработки. В начале года у меня появилось немного свободного времени, и я решил заняться проектированием довольно сложного Web-сервера. Он представляет собой кучу страниц Java Server Pages, предназначенных для управления лабораторией и архивом корпоративных документов. Но основная моя задача заключалась в том, чтобы разработать необходимый инструментарий средства. Не буду скрывать, мне интересно создавать инструменты для тех, кому приходится писать код.

Большинство создателей современных средств проектирования программ пытаются по мере возможности избавить разработчика от ввода кода вручную при проектировании элементов пользовательского интерфейса или базы данных. В процессе написания кода вы работаете как телетайп, в лучшем случае текстовый редактор выделяет цветом ключевые слова. Так называемые «высокие технологии» немного помогают при наборе операторов, но на этом, собственно, все и заканчивается.

В последнее время моя работа заключалась в упорядочении идей, предусматривающих представление программы в виде алгебраической структуры и выполнение соответствующих алгебраических преобразований. Все это весьма занятно и интересно.

Джеймс Гослинг: «Я всегда помню о том, что совершенствование вычислительной техники подчиняется закону Мура — а это геометрическая прогрессия»

Говоря об алгебраических преобразованиях, вы имели в виду перестройку программы?

Да. К примеру, моя программа позволяет переименовывать классы. Переименование класса на одном уровне иерархии не представляет ничего сложного — достаточно просто поменять имя. Но как отразить изменения во всех ссылках на данный класс и во всех операциях импорта? А если еще рассмотреть переименование, включающее в себя перенос класса из одной группы в другую? Я решал эту задачу путем переопределения всех списков импорта с последующим разрешением конфликтов имен. Но здесь нужно пойти дальше.

Выйдет ли когда-нибудь этот инструментарий за пределы Sun?

Да. Если мне удастся довести свою работу до намеченного состояния, она должна вызвать немалый интерес. Надеюсь, в перспективе мне удастся вынести ее на суд широкой публики.

В последних интервью вы заявляли, что основные трудности, с которыми приходится бороться программисту, обусловлены сложностью программного обеспечения. Не могли бы вы пояснить, что под этим подразумевается?

В некотором смысле ответ на данный вопрос дает тот инструмент, созданием которого я сейчас занимаюсь. Как вы планируете разрабатывать сложное приложение? Что собираетесь делать с программой длиною в миллион строк? Каким образом будете вникать в логику его работы? Как намереваетесь осуществлять переход к подобной системе? Как вообще с ней можно совладать?

Новые трудности возникают при размещении приложения в Сети. Положительной чертой Java является возможность однородного представления действительности, которая на самом деле однородностью не отличается. Одним из наиболее «горячих» направлений в последнее время стал бизнес, связанный с сотовыми телефонами. По тем сведениям, которые у меня имеются, сейчас в мире ежедневно продаются десятки тысяч сотовых телефонов с поддержкой Java. Эти цифры поражают воображение. Еще большие темпы роста демонстрируют решения, связанные со смарт-картами. Многие сегодня разрабатывают приложения, обеспечивающие связь между периферийными и центральными узлами сети. Отдельные части приложения независимо от особенностей конкретного устройства, подключаемого к сети — будь то настольный компьютер, сотовый телефон или PDA, — должны одновременно являться компонентами инфраструктуры, элементами основной бизнес-логики и баз данных. Конечно, проектирование этой сложной архитектуры можно поручить одному человеку, но справится ли он с такой задачей?

У нас пока действительно нет бесспорных решений. Имеются лишь инструменты, позволяющие взглянуть на то, что делает какая-то одна система, и перенести это на всю сквозную архитектуру. Некоторые используют отладчики. Но как проанализировать отладчиком код, находящийся внутри базы данных Oracle? Как обобщить всю имеющуюся информацию? Это серьезный и интересный вопрос. Программные системы с каждым днем становятся все более и более сложными.

Пару лет назад я много времени потратил на создание инструментов, помогающих в разработке систем реального времени. Основная посылка состояла в том, что программист больше не должен вручную писать несколько тысяч строк ассемблерного кода. Системы действительно становились огромными. А технология Java к тому времени уже успела проявить себя с самой лучшей стороны в проектах создания больших и надежных систем.

Некоторые из подобных изолированных приложений, находящихся на одной машине, включают в себя миллионы строк кода. Как можно иметь с ними дело? Большинство людей не имеют понятия об этом. Сегодня нам доступны все виды инструментов, начиная с организационных, получаемых на основе объектно-ориентированной методологии, и заканчивая средствами, построенными на их базе, например, моделями UML.

Но чем больше средств вы создаете, чтобы справиться с имеющимися трудностями, тем более сложные вещи появляются вновь. Мы всегда ограничены в понимании конструируемых объектов — будь то программное обеспечение или небоскребы.

Повышение сложности обусловлено и особенностями оборудования, которое становится все более мощным и дешевым.

Безусловно. Я всегда помню о том, что совершенствование вычислительной техники подчиняется закону Мура — а это геометрическая прогрессия.

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

Это действительно является одним из основных моих жизненных принципов, и работает он достаточно хорошо. Переехав на новую квартиру, не спешите распаковывать вещи. Просто расставьте ящики в нужном порядке и доставайте из них то, что вам нужно, по мере необходимости. После того как обживетесь в квартире в течение двух-трех месяцев, возьмите ящики с оставшимися в них вещами и, даже не открывая их, со спокойной душой выбросьте все содержимое на свалку.

Ящики, которые «даже не следует открывать», крайне важны, ведь очень трудно выбросить вещь, ценность которой хорошо себе представляешь.

Правильно, потому что стоит их открыть, как сразу станет ясно, что с ними действительно ни в коем случае нельзя расставаться.

Так вы хотите сказать, что простота должна стать основным критерием выбора разработчиков, и что они обязаны следовать этой философии при проектировании программ?

Я полагаю, что при проектировании всегда нужно стараться найти наиболее простой путь. Если этого не получится, вы окажетесь погребенными под грузом проблем. Справиться с подобными трудностями совсем не просто.

Одной из общих черт эволюционного развития языков программирования является усложнение языка до такой степени, что никто не может его понять. Я провел эксперимент, попытавшись добиться от программистов изложения правил выполнения арифметических операций с беззнаковыми переменными в Си. Кое-какие очевидные вещи они поняли, но многие из опрошенных не уловили даже и этого.

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

На вопрос о том, что следовало сделать по-другому, если бы пришлось проектировать Java заново, вы отвечаете, что ориентировались бы на разработку механизма делегирования полномочий.

Да.

Имеете ли вы имеете в виду отказ от наследования классов и распространение наследования только на интерфейс и композицию?

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

И все же что понимается под делегированием полномочий? То, что один объект делегирует их другому без определения подкласса?

Да, без поддержки иерархии наследования. Вместо создания подклассов вы используете чистые интерфейсы. Речь идет не о том, что технология наследования классов плоха сама по себе. Но при ее использовании возникают определенные трудности.

На пляжах Санта-Круз большой популярностью пользуется игра Whack-a-Mole («Ударь крота»). На игровом поле находится стол с 16 отверстиями. Маленький механический крот на секунду высовывает из дырки голову. Ваша задача — ударить его палкой. Голова крота появляется в одном из отверстий, вы ударяете по ней, после чего она показывается в другом отверстии и т.д.

Процесс проектирования во многом напоминает игру Whack-a-Mole. То здесь, то там у вас возникают какие-то осложнения. Вы «бьете по ним палкой», и они исчезают. Но вот вопрос: действительно ли вы устранили все имеющиеся препятствия, или через некоторое время они появятся вновь, но уже в другом месте? Зачастую трудно сказать, действительно ли устранена проблема, или исчезли только ее внешние проявления. Я чувствую, что делегирование полномочий поможет мне справиться с определенными трудностями, но не повлечет ли она за собой другие осложнения? Данная технология пока не используется повсеместно, поэтому, возможно, число проблем даже возрастет.

Практически наверняка вам не удастся найти универсальное решение, которое полностью отвечало бы на все эти вопросы. Вы можете лишь выбирать из нескольких зол наименьшее.

Учитывая то, что в Java поддерживается наследование как классов, так и интерфейсов, можете ли вы посоветовать что-либо тем, кто пытается решить для себя, какой из методов лучше использовать? Когда лучше остановиться на расширении классов, а когда отдать предпочтение наследованию интерфейса и композиции?

Конечно, хотелось бы, чтобы существовало какое-то четкое правило, поскольку и сам довольно часто оказываюсь в состоянии неопределенности. Могу сказать лишь, что лично я применяю наследование чаще, чем какую-либо другую технологию.

Под наследованием понимается расширение класса?

Расширение класса. Я использую классы чаще, чем интерфейсы, но не могу четко объяснить почему. Интерфейсы служат для решения действительно абстрактных и действительно ясных задач — для описания чего-то исполняемого или выводимого на печать. Я привык поступать так, но может быть, интерфейсы следует использовать чаще.

Года два назад вы сказали примерно следующее: «Уединиться в комнате и заниматься исключительно написанием программного обеспечения не получится. Это один из видов социальной деятельности». Не так давно я втянулся в работу сообщества Jini и начал принимать участие в согласовании процедуры проектирования стандартных API-интерфейсов. В период становления Java вас можно было охарактеризовать как благожелательного диктатора. Сейчас эта роль отводится сообществу Java Community Process.

Правильно. Сегодня я являюсь скорее незаметным наблюдателем.

Если уж речь зашла о вашей роли стороннего наблюдателя, можете ли вы дать какую-то характеристику сообществу Jini? В чем сходство с Java Community Process? В чем отличия? Что можно было бы улучшить?

Один из самых важных моментов — соглашение о реализации справочного руководства. Чернила на спецификациях не высохнут до тех пор, пока кто-то продолжает эти спецификации дописывать.

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

Понимаю. Не знаю, явились ли инициаторами этого процесса Рон Голдман и Дик Гэбриел, представившие первый черновой вариант Jini, или же кто-то еще, но с самого начала сторонники Jini разделились на два лагеря. Первый лагерь, коммерческий, представлен людьми, вложившими в технологию реальные деньги. Они стремятся оказывать активное влияние на ее эволюцию. Второй лагерь составляют кабинетные инженеры, которых интересует только технология. Для того чтобы спецификации были утверждены, необходимо согласие представителей обоих лагерей. Это напоминает очередной эксперимент по поддержанию необходимого баланса между коммерческими и техническими вопросами. Лично я не уверен, что при таких условиях все действительно будет хорошо работать.

Это на самом деле непростой вопрос. В истории компьютерной отрасли полно примеров, когда решения принимались недостаточно компетентными людьми. Поэтому отдельные компоненты технологии оставляли желать лучшего.

Все это довольно сложно. Конечно, хотелось бы, чтобы на любой вопрос можно было дать четкий и правильный ответ, но политические игры начинаются всякий раз, когда в комнате собирается больше одного человека.

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

Да, это одна из тех вещей, которой не учат в школах. Одним из наиболее сложных моментов при решении любой инженерной задачи является налаживание межличностных контактов. Независимо от того, где вы находитесь, вам все равно придется общаться с другими людьми.

Поделитесь материалом с коллегами и друзьями