Может быть, провокационный вопрос: а кто ваши конкуренты?
Д.Г.: Тут нельзя ответить однозначно. Если речь идет о Java, то, может, в некоторых областях - .NET. Если об инструментарии, то, пожалуй, IBM и Microsoft. Если же об аппаратуре - я бы назвал HP, IBM, Dell.
А.Б.: Хочу добавить: меня, как ни странно, порадовало бы, если б в России открыла свой центр разработки компания Google. Там тоже высоко ценят инженерный талант. Для нас это было бы важным знаком, к тому же очень интересно взглянуть на динамику развития рынка в такой ситуации…
Не боитесь, что они уведут ваших разработчиков?
А.Б.: Да нет, каждый выбирает ту атмосферу, в которой ему лучше работать, у нас она уникальная - вряд ли уйдут. Разработчики смогут выбирать между той или иной идеологией управления.
А что желают ваши клиенты? Что их сейчас волнует?
Д.Г.: Клиентам нужно все! Я бы выделил масштабируемость, надежность и облегчение последующей разработки приложений. Еще в фаворе совместимость с продуктами Microsoft (в первую очередь на основе .NET и веб-сервисов).
А можно использовать и то и другое, или лучше выбрать что-то одно?
Д.Г.: Можно серверную часть сделать на Java, клиенты - на .NET, но мое личное мнение - что смешивать не надо, это всегда хуже управляется.
А какие, на ваш взгляд, недостатки есть у технологии .NET?
Д.Г.: О, это нетрудно. Из основных - плохая производительность в крупных системах; технология не реализована ни в Linux, ни в системах Apple, ни в таких устройствах, как смартфоны. Это решение одного производителя, так что вы вынуждены рассчитывать только на одного поставщика. Вы не можете сравнить конкурирующие продукты и выбрать лучший. Решения же на основе Java предлагает множество компаний, и вы всегда можете остановиться на том, которое вам нужно, и за те деньги, которые вас устраивают. Для примера могу привести конкурирующие решения от IBM и Oracle.
Вы раньше сотрудничали с компанией Microsoft. Сейчас у вас есть какие-либо совместные проекты?
Д.Г.: Тесного сотрудничества у нас никогда не было. Чаще между нами возникали конфликты, потому что наша работа противоречит бизнес-процедурам и идеологии Microsoft. Однако мы участвуем вместе с этой компанией в выработке стандартов для веб-сервисов. Сейчас мы тесно сотрудничаем в области разработки технологий идентификации пользователя, здесь у нас много общих интересов.
Сейчас активно обсуждается тема безопасности. Особенно пользователей беспокоит ситуация со смартфонами. Вы хорошо знаете историю с SymbianOS и вирусами для нее…
Д.Г.: Java - абсолютно безопасный и защищенный язык. У него нет проблем с безопасностью. Эти вирусы эксплуатируют вовсе не слабости языка Java, а ошибки в конкретной реализации протокола Bluetooth. Кстати, мы наняли разработчика вирусов для этой системы. Очень умный и хороший программист.
А как же проблемы с совместимостью? Ведь не секрет, что скачанное из Интернета для веб-браузера я не могу запустить на телефоне, а игры с телефона бесполезно запускать на, к примеру, КПК…
Д.Г.: Проблема несовместимости в основном касается первого поколения смартфонов, в которых реализация Java не полностью соответствовала спецификациям. Мы сейчас активно работаем с производителями, и во втором поколении смартфонов спецификации соблюдаются уже более точно. Потом надо понимать, что есть большая разница между корпоративными приложениями, где важна абсолютная платформонезависимость, и играми для смартфонов, где есть такие параметры, как разрешение экрана и видеоускорение. Как правило, программисты игр сознательно идут на использование специальных возможностей конкретной реализации Java в ущерб стандартам и спецификациям. В корпоративном секторе таких проблем нет.
Увеличение абстракции языка программирования повышает требования к аппаратному обеспечению. Чем легче программисту, тем труднее конечному пользователю: ему приходится постоянно обновлять аппаратное обеспечение. Не приведет ли дальнейшее развитие языка Java к такой «гонке вооружений»?
Д.Г.: Да, это проблема Java. И все же если сравнивать производительность с программами на C и C++, то Java нередко выигрывает. Особенно в системах хранения данных. В этих языках дорого обходится независимость от аппаратного обеспечения. Когда мы говорим про продукты на С и С++, оптимизация нужна. Особенно для нестандартных процессоров. У Java же нет необходимости модифицировать саму программу. Она будет работать везде, где реализована виртуальная Java-машина (JVM). Достаточно один раз хорошо сделать (строго следуя спецификациям) JVM, и у вас будет работать любое программное обеспечение, иногда даже быстрее ассемблерного кода, написанного неспециалистом. Компилятор конкретной виртуальной машины уже оптимизирован профессионалами под ту платформу, на которой она реализована. Поэтому Java-приложения работают очень быстро.
Вы сказали - компилятор, то есть здесь как бы двухэтапная компиляция?
Д.Г.: Да, технология даже состоит, скорее, из трех этапов: в среде разработки пишется программа на Java, вы отлаживаете ее там и встроенным компилятором получаете универсальный байт-код. Затем вы этот код можете запустить на любой виртуальной машине, где он будет оптимально откомпилирован под конкретный процессор.
Ну хорошо, давайте поговорим об OpenSolaris[opensolaris.org/os. Суть проекта - в открытии исходных кодов операционной системы Sun Solaris. Однако лицензия CDDL, под которой распространяется ее код, не эквивалентна лицензии GPL, хотя и имеет с нею много общих положений]. Какие надежды вы на нее возлагали и оправдались ли они?
Д.Г.: Язык Java открыт уже больше десяти лет, и это очень способствовало разработке и совершенствованию технологии. Многие проблемы были обнаружены на самой ранней стадии, и мы благодарны энтузиастам, которые помогли их исправить. Проект OpenSolaris стартовал совсем недавно, так что выводы делать рано. Мы, разумеется, ожидаем позитивный результат. Главная цель этого шага - вовлечение в совершенствование продукта наших клиентов. Мы хотим их сделать нашими партнерами.
Мы не только ждем развития Solaris от сторонних разработчиков, в других системах уже появляются и наши решения. Например, утилита DTrace, которой мы по праву гордимся, портирована во FreeBSD.
Не планируете ли вы выйти с Solaris на рынок конечных пользователей?
Д.Г.: Мы вообще очень любим конечных пользователей, однако пока нет идеи, каким образом на этом рынке можно работать. У нас нет бизнес-модели. Нужно иметь обширную службу поддержки. Операционная система должна быть протестирована и отлажена на большом количестве оборудования и т. п. В общем, мы пока не думаем на эту тему.
Участвует ли Sun в государственных программах, включая такие неоднозначные, как Digital Passport?
Д.Г.: Да, мы участвуем во множестве различных государственных программ. Наиболее тесно компания сотрудничает с государственными учреждениями Бразилии. Там уже работают наши решения в системе здравоохранения и в налоговой службе.
А.Б.: Насколько я знаю, в России Sun не работает напрямую с клиентами, но наши партнеры участвуют в подобных программах. Однако представителей Sun нередко приглашают на правительственные совещания для консультаций.
Java использовался в марсианском проекте, вы не расскажете подробности?
Д.Г.: В первой части проекта использовался язык Java, но только в наземном оборудовании. В самих марсоходах, которые бороздят поверхность четвертой планеты, применены другие технологии. Однако американский президент решил поскорее отправить на Марс человека, и вторая часть проекта, связанная с посылкой автоматизированных систем, приостановлена. Хотя многое уже было сделано.
Вы, конечно, знаете об ANSI C, ведь это тоже универсальный стандартизованный язык, так зачем понадобилась Java?
Д.Г.: Если писать сложные программы, особенно для очень разных платформ, то проект на основе ANSI C будет долгим и дорогим. На Java решение таких задач обходится вдвое дешевле. К тому же у Java более понятный код и проще отладка. В программе на С очень трудно искать ошибки, так как место ошибки и место ее проявления могут быть сильно разнесены в тексте программного проекта. Например, если вы ошибетесь в хедере[Часть программы на С с описаниями переменных и классов, которая может быть вынесена в отдельный файл], то выловить эту ошибку порой невероятно трудно. В Java баги так глубоко не прячутся, и обнаружить их чаще всего не составляет труда.
