InfoWorld, США

Должна ли платформа Java быть свободно распространяемой?

Род Джонсон — известная фигура в сообществе разработчиков Java. Он предложил платформу Spring Framework for Java, дает консультации и пишет книги, среди которых Expert One-on-One J2EE Design и Development и Expert One-on-One J2EE Development without EJB. Кроме того, он является генеральным директором международной консалтинговой компании Interface21. Джонсон ответил на вопросы ответственного редактора еженедельника InfoWorld Пола Крила, встретившись с ним во время симпозиума TheServerSide Java Symposium, состоявшегося в Лас-Вегасе в конце марта.

Что, по-вашему, мешает упростить программирование на Java и насколько необходимо такое упрощение?

Сам по себе язык Java уже значительно упрощает многие конструкции, особенно в сравнении с C++. И я думаю, что с выпуском Java 5 такое упрощение на уровне языка будет продолжено. С самыми большими сложностями приходится сталкиваться при создании Java-программ, выполняемых на сервере. Однако за последние несколько лет мы добились значительного прогресса в разработке на базе POJO (Plain Old Java Objects). Безусловно, сейчас создавать серверные модули на Java стало значительно проще, чем с исходной моделью J2EE.

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

Род Джонсон: «Если бы проект, связанный со свободно распространяемым вариантом Java, оказался достаточно успешным, кому бы то ни было создавать свой собственный вариант Java не имело бы никакого смысла. Так что Java вряд ли угрожает ?раздробленность?»

Аспектно-ориентированное программирование по сути дополняет объектно-ориентированное программирование. ООП — очень результативная парадигма, и одно из главных достоинств этого метода состоит в том, что он действительно стимулирует повторное использование программ и помогает избавиться от дублирования. Так, например, если у вас есть класс «счет» и вы создаете наследуемые классы, такие как «сберегательный счет», «счет до востребования», «кредитный счет» и так далее, у вас есть очень неплохая возможность употребить эту иерархию для инкапсуляции логики, которую вы хотите повторно использовать. Однако здесь есть и неприятный момент, который связан с так называемой «сквозной функциональностью» (crosscutting). Сквозная функциональность — это элементы функциональности, которые могут применяться ко всей системе. При реализации традиционной объектно-ориентированной модели она затрагивает множество классов и методов. Возьмем, например, понятие аудита. Существует, конечно, возможность реализовать вспомогательную функциональность в базовом классе, предположим, в классе «счет», в который будут, в частности, предусмотрены аудиторские функции. Но что произойдет, если, скажем, необходимо вести аудит каждого метода, который приводит к изменениям в состоянии сберегательного счета? При классическом объектно-ориентированном моделировании в этом случае избежать дублирования не удастся. В конце концов код для выполнения аудиторских функций окажется распределен между множеством методов. Положение ухудшится в том случае, если аудит сберегательных счетов должен применяться к различным областям функциональности, таким как товарные запасы, адреса и так далее. Дублирование становится еще больше. Поэтому аспектно-ориентированное программирование вводит понятие аспекта. Аспект — это способ формировать из модулей код, который будет воплощать сквозную функциональность. С помощью платформы Spring Framework управление транзакциями и защита реализуются на основе аспектного подхода, поэтому пользователям не нужно в обязательном порядке работать с конструкциями ООП, но они тем не менее получают преимущества от модульности кода, который, в противном случае, оказался бы «размазанным» по всей программе.

Расскажите о вашей роли в разработке Spring Framework. Не могли бы вы также коротко сравнить Spring с другими платформами, такими как JavaServer Faces (JSF) и WebWork?

Идеи, на фундаменте которых была создана Spring Framework, я изложил в своей первой книге, посвященной J2EE. Эта книга издана в 2002 году, и она стала одним из факторов, которые дали старт так называемой «революции упрощений» в J2EE. В книге рассказывалось о том, почему традиционная модель оказалась столь сложной. Одновременно я опубликовал 30 тыс. строк кода, который должен был проиллюстрировать мою точку зрения на то, как с помощью платформы приложений можно значительно упростить разработку.

Многих читателей мои идеи заинтересовали, и очень скоро меня стали уговаривать приступить к реализации такого проекта. Поэтому в начале 2003 года мы приступили к разработке. Spring, по сравнению с другими платформами, создала для себя особую нишу. По сути, это прикладная платформа, которая затрагивает многие уровни архитектуры. Такие платформы, как Struts или WebWork, преимущественно, касаются только одного архитектурного уровня. Поэтому Struts и WebWork — это Web-платформы. Если сравнивать Spring с JSF, то они имеют разное предназначение. JSF — это, по существу, компонентная модель для представления Web-ресурсов, в то время как Spring — в большей степени платформа, предназначенная для формирования общей структуры и синхронизации с вашим приложением. Поэтому Spring можно использовать совместно с JSF. Причем Spring предлагает свою собственную Web-платформу, построенную по принципу MVC («модель — представление — контроллер»), которую можно рассматривать как альтернативу Struts и WebWork. Но, с другой стороны, Spring — это модульная платформа.

Вы как-то сказали, что Java Community Process напоминает вам стиль советской плановой экономики. Вы не могли бы пояснить свои слова?

Я думаю, что речь шла о прежнем подходе, и, надо отдать должное JCP, сейчас ситуация начинает меняться. Но изначально JCP предполагал работу комитета, в котором, как правило, доминируют производители, определяющие модель программирования. Недостатки этого подхода заключаются в том, что он, по большому счету, не основывался ни на конкуренции, ни на опыте. Поэтому достаточно сложные модели программирования, такие как оригинальная модель программирования Enterprise JavaBeans (EJB), определялись группами людей, которые приложений не разрабатывают. Они разрабатывают серверы. Противопоставляя капитализм советской системе, я хотел подчеркнуть, что прежний подход навязывал разработчикам далеко не оптимальную для них модель. Он определял путь развития на несколько следующих лет. И это означало, что, если некое потенциальное решение окажется не очень хорошим, от него все равно долгое время не смогут отказаться. Это серьезно ограничивало возможность создать что-то новое, например, в бизнесе или там, где жесткая конкуренция заставляет людей использовать инновационные решения.

Должна ли платформа Java быть свободно распространяемой, учитывая, что в Sun Microsystems отказались в отношении нее от жесткого контроля?

У меня нет четкого мнения по этому поводу. Я процитирую старое изречение: «Не пытайся чинить то, что не сломано». Я думаю, что Sun делает много хорошего в отношении Java как языка. И несмотря на то, что есть достаточно весомые аргументы в пользу того, чтобы сделать технологии Java свободно распространяемыми, я думаю, что не менее весомые аргументы существуют и в пользу иной точки зрения: если все идет достаточно гладко, не нужно вмешиваться. Что касается ряда других элементов этой платформы, то, скорее всего, настало время признать, что свободно распространяемые программы сейчас играют весьма важную роль в создании инновационных решений и в определении методов работы людей. И мне кажется, что мы должны подумать о том, не следует ли в некоторых областях несколько уменьшить роль JCP.

Что мы приобретем и что можем потерять, если Java станет свободно распространяемым?

Появится возможность многое исправить в языке. Так, о многих ошибках в платформе известно давно. Главным образом, незначительных, конечно. Я думаю, что в целом Java очень стабилен, и тем не менее если он станет свободно распространяемым, то очень многие ошибки будут исправлены значительно быстрее, чем это происходит сейчас. Хорошо известно о Java Bug Parade — списке проблем, которые не могут устранить годами. Думаю, они-то были бы решены достаточно быстро. Скорее всего, возникнет много других компаний, помимо Sun, которые будут проявлять большой интерес к Java, и, если все будет сделано аккуратно, можно будет избежать многих потенциальных негативных моментов. В случае, если Java станет свободно распространяемым, мне кажется крайне важным наличие достаточно жесткого контроля со стороны какой-нибудь организации, возможно, некоммерческой. На мой взгляд, это более эффективный подход, чем модель, при которой очень большая группа заинтересованных сторон все время контролирует код и в результате становится сложно гарантировать стабильность платформы.

Наличие определенного контроля предотвращает появление множества разных вариантов Java, не так ли?

Вряд ли появилось бы множество вариантов… Создание таких вариантов — достаточно радикальная вещь. Откровенно говоря, если бы проект, связанный со свободно распространяемым вариантом Java, оказался достаточно успешным, кому бы то ни было создавать свой собственный вариант Java не имело бы никакого смысла. Так что Java вряд ли угрожает «раздробленность».

Вам не кажется, что интерес к AJAX (Asynchronous JavaScript and XML) в какой-то мере нагнетается искусственно?

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

Какие технологии могут придти на смену Java или превзойти его?

Если оценивать Java с точки зрения жизненного цикла языка, очевидно, что его можно назвать достаточно зрелым. Безусловно, растет интерес к динамическим языкам, таким как Ruby и Python. Я думаю, очень важно то, что Java Virtual Machine и Java — это разные вещи. Java, скорее всего, навсегда останется основным языком, который работает на JVM. Но мы должны понимать, что платформа Java может потенциально ограничивать выбор языков программирования. Существовала масса интересных разработок, таких как Groovy, созданных сообществом Java и являющихся очень краткими и во многих отношениях мощными языками. Кроме того, существуют также «Java-версии» популярных языков, такие как JRuby. Именно этого, помимо прочего, мы пытаемся добиться в Spring 2.0. Сейчас мы реализуем компонентную модель Spring для того, чтобы она поддерживала любой язык, который работает на JVM. Есть множество интересных разработок, связанных с переносом динамических языков на платформу Java. Я хочу также отметить, что Java остается весьма стабильным, и крайне важно, чтобы он продолжал развиваться. Хотя Java 5 уже стал значительным шагом вперед, Java как язык должен совершенствоваться и дальше. Как только он перестанет развиваться, он начнет умирать.

И как он будет развиваться?

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

Каковы ваши впечатления от технологий Microsoft .Net?

Я думаю, что .Net — надежная платформа. Это очень серьезный конкурент для корпоративных технологий Java. В .Net реализовано немало интересных возможностей — например, возможность использовать различные языки. Кроме того, Microsoft ведет очень интересную работу, связанную с языками, созданными специально для конкретной предметной области (Domain Specific Language, DSL), и уже предложила немало действительно инновационных решений в языке C#.