Много лет прошло со времени, когда мысли о Java впервые зародились в головах разработчиков из фирмы SUN. Им хотелось создать язык для управления бытовой техникой, или, как еще говорят, "встроенными системами". С тех пор вид и назначение этого языка разительно менялись, так что прошлое, настоящее и будущее его, даже трудно сопоставить. Тем не менее, мы этим займемся. Начав с самого начала, мы попытаемся проанализировать развитие Java и понять чем вызвана столь высокая ее популярность сейчас, и что, быть может, станет причиной ее смерти в будущем.

Эта статья (как и всякая историко-футурологическая спекуляция) не претендует даже на объективность. Однако, большинство изложенных в ней фактов верны, а для иллюстрации некоторых положений используются примеры программ. Я постараюсь вести изложение так, чтобы даже незнакомый с языком читатель смог вынести из него полезную информацию, а профессионал нашел подтверждение своих мыслей ранее не выраженных вербально. Во избежание недоразумуний сразу оговорюсь, что под Java я понимаю не только сам язык но и технологию.

1. Рождение.
1.1. Первые опыты.
Как известно, первоначально Java (которая тогда была еще не Java а Oak) предназначалась для управления бытовой техникой. (Видимо, именно эта техника наиболее подходящий "объект" для обкатки различных OO технологий. Вспомним, что и Страуструп придумал свое "C с классами" для управления телефонными станциями Bell (что не совсем бытовая, но техника)). Джеймс Гослинг (легендарная личность в мире UNIX) быстро понял что его не удовлетворяют классические языки программирования (тот же С++). Быстродействие он променял на надежность, создав в результате замену С++ в "домашнем хозяйстве". Все это происходило в 1991 году, когда до появления Java было ох как далеко. Язык Oak был положен в основу устройства, которое затем было представлено руководству SUN. Грубо говоря - это был универсальный пульт управления бытовыми приборами со "средствами multimedia", как принято говорить сейчас. Руководство не осталось равнодушным. Уже с этого момента стало ясно, к проектам какого типа тяготеет Oak. В своем отзыве президент Sun писал: "Нам нужно этого щенка продать как следует... Мы убьем HP, IBM, Microsoft и Apple одним ударом".

1.2. "Новые" идеи в Java.
Марк Андреессен (создатель NetScape), впервые увидев Java, сказал: "то, что делают эти ребята, абсолютно и неопровержимо ново. Это классная штука". Так ли это? Попробуем беспристрастно ответить на данный вопрос по прошествии нескольких лет. Какие "абсолютно новые идеи" приписывают Java? Очевидно, компиляцию в байт-код (дающую кросс-платформенность), объектную ориентированность, автоматическую сборку мусора и еще некоторые мелочи. Итак, что же здесь действительно нового?

1.2.1. Идея байт-кода.
Идея компиляции в некую промежуточную абстрактную форму ("псевдоассемблер" а не ассемблер целевой машины) почти также стара, как и идея компилятора. Наиболее классическим примером можно считать язык Forth. А компания IBM создала и давно использует целую архитектуру (AS/400), ассемблер нижнего уровня которой недоступен. Это позволяет ей вот уже на протяжении многих лет менять аппаратную платформу прозрачно не только для пользователя, но и для программиста. Самым близким по идеологии к Java очевидно является язык SmallTalk. Большинство его реализаций имеют ту же двухуровневую архитектуру, что и Java, гдн собственно SmallTalk транслируется в байт-код очень напоминающий байт-код JVM (Java Virtual Machine - виртуальная машина Java) SUN. Такой подход был популярен еще в 80-е годы и сейчас интерес к нему снова возрастает. Существуют и более современные реинкарнации этой идеи. Так, Inferno (весьма интересный проект фирмы Lucent о котором будет рассказано ниже) тоже базируется на байт-коде, причем существенно более элегантном и "продвинутом" чем байт-код JVM.

1.2.2. Идея ООП.
Второй "огромный прорыв" Java - объектная ориентированность. Она рекламируется как "очищенная и улучшенная" (f.e. отсутствие множественного наследования) по cравнению с С++. Тут уместно дать слово создателю C++ Бьерну Страуструпу. Он писал что несмотря на сходный синтаксис Java "фундаментально иной язык поддерживающий отличную от C++ культуру и иные (на самом деле более ограниченные) стили программирования)... От Java ждут очень многого, в связи с интеграцией с Web, и эти ожидания подстегиваются дорогостоящими маркетинговыми акциями. Время покажет, будет ли Java дееспособен как универсальный язык... Если же вернуться к сравнению С++ и Java, то вспомним следующие фундаментальные характеристики С++: абстракция данных; поддержка OOP; обобщенные классы. Изо всех этих особенностей применительно к Java в полной мере можно говорить лишь об OOP, которое, реализуется здесь иначе чем в С++". Как видим, характеристика далеко не блестящая. В области ООП трудно отдать Java пальму первенства. Тем более, что это гибридный, а не чисто объектный язык.

1.2.3. Идея сборки мусора и отказ от указателей.
Наконец мы доходим до технических деталей, таких как сборка мусора и отказ от указателей. Как вы помните, в Java нет необходимости отменять заказанную память, (более того - нет даже такой возможности!) поскольку существует волшебная вещь - сборщик мусора (garbage collector). Он сам освободит память за нас, когда объект, занимавший ее, перестанет существовать. Единственное что может сделать программист - явно вызвать сборщик мусора. Нет больше утомительной работы с new и delete, указателей и ошибок с ними связанных. Вспомним теперь один из самых "старых" и заслуженных языков прошлого - LISP. Именно на нем много лет "обкатывались" технологии автоматической сборки мусора, став к 90-м годам чем-то вроде классики программирования. То же можно сказать и о SmallTalk.

1.3. "Преимущества Java".
Кроме новых идей, Java претендует и на наличие "преимуществ", которые получает программист использующий ее. Для полноты картиныя мы рассмотрим их в следующих пунктах, и выясним, действительно ли они столь велики, как об этом говорит SUN.

1.3.4. Сетевая поддержка.
Сетевое программирование - вот область где Java "далеко опережает остальные языки программирования". Действительно, в Java (точнее, в его стандартную библиотеку) входят сетевые средства. Впрочем, не следует толковать это утверждение расширительно. На самом деле имеется ввиду поддержка стека протоколов TCP/IP. Точнее - TCP и UDP, а также HTTP (обусловлено модой на WWW), и ничего более. Ни о каких других протоколах речь не идет. Не дай вам бог заикнуться о поддержке SNA или DECNet - для этого был и остается банальный C. Иными словами - все нестандартные и низкоуровневые сервисы остаются за бортом. Они вам нужны? Что ж, можете запрограммировать сами!

Другая область, заслуги в которой традиционно приписываются Java - это распределенные вычисления. Однако и тут Java не в первых рядах. Единственный примитив из этой области, данный программисту - цепочки или нити (threads) - аналог виртуального процессора со своим контекстом. Как бесплатное приложение к нему имеются семафоры. Стоит правда заметить, что указанные примитивы НИКАК не поддержаны на нижнем уровне (уровне байт-кода). Там имеется лишь одно средство - вход и выход из критической секции. Вообще, Java неоднократно подвергалась критике за ограниченность своего "низкоуровневого" ядра. Ни многозадачность, ни распределенность не вошли в него. Очевидно, на это у авторов Java и фирмы SUN не хватило фантазии (вероятно из за ограниченных ресурсов кофеварок и мясорубок, где никто не слыхивал о страничном обмене и параллельных вычислениях (хотя даже кофеварка может готовить одновременно 2 чашки кофе)). Другая проблема распараллеливания лежит еще ниже - на уровне архитектуры JVM. Как известно, JVM имеет стековую архитектуру. То есть следующая команда берет с вершины стека результаты выполнения предыдущей. А значит, до завершения первой операции, вторая не может быть начата. Такая зависимость сильно затрудняет распараллеливание одной задачи на нескольких процессорах.

Наконец, коснемся последнего из рассматриваемых преимуществ - поддержки графики. Сразу оговоримся, что имеется в виду AWT (abstract window toolkit) поставляемое с Java 1.1.x AWT 1.0.2 я не рассматриваею из за примитивной модели событий свойственной ему. В AWT 1.1.x входят лишь стандартные элементы, (кнопки, поля редактирования, listbox-ы). Сложные объекты, такие как Grid или Tree там просто отсутствуют. Конечно, их можно написать или купить -но оба эти решения не лишены недостатков. Помимо этого, стандартные элементы рисуются в Java посредством вызова системных процедур для данного объекта, поэтому в каждой OC интерфейс написанный на Java выглядит по-разному, в зависимости от установленного оконного менеджера, будь то Windows GUI, PM, или X11. Нет единства того, что сейчас называется "Look & Feel" - одинаково выглядящего интерфейса в разных системах. Как результат - многие программы, написанные в Windows трудно использовать в UNIX. В последней версии Java этот недостаток преодолевается посредством Swing. Но это отдельная тема.

Итак, ни с "теоретической" ни с "технической" точки зрения Java не демонстрирует новых или особо продвинутых идей. Конечно, можно возразить, что только в ней собраны все те полезные свойства, которые мы перечислил. Я не согласен с этим мнением, но это уже вопрос личных пристрастий автора. Была ли такая компоновка удачной, или лучше было остановиться на другой - покажет время.

2. Жизнь.
2.0. Java - унесенная солнечным ветром.
Богом, или президентом SUN, новому языку Oak была уготована долгая жизнь. SUN просто не мог выкинуть несколько человеко-лет работы своих ведущих разработчиков на свалку. После неудач с применением Oak в бытовой технике нужно было срочно найти ему новое выгодное применение. Напомним, что до этого Oak предполагалось использовать в сотовой телефонии, интерактивном телевидении и игровых приставках. Все эти проекты сорвались. Как говорил сам Гослинг "В чем мы действительно оказались тупыми - это в том, что сосредоточились на приставках, и отгородились от остального мира шорами". Разработчики Java еще раз почувствовали на себе известную им истину: "производители бытовой электроники привыкли платить только за микропроцессоры, которые упрощают использование их продуктов". Миру телевизоров и холодильников не нужен был новый универсальный кросс-платформенный язык программирования. Между тем, руководство SUN требовало прибыли, и желательно как можно скорее. Наконец, было принято верное решение - поставить на Internet и бесплатное распространение технологии. В 1995 году Oak был переименован в Java и выпущен в свет. Как случилось, что SUN проглядел развитие WWW, опоздав минимум на полтора года - мы уже вряд ли узнаем.

2.1. Типы проектов.
Проекты бывают разные, как и языки. Я поделю проекты на 3 группы (которые, разумеется, практически не встречаются в чистом виде): коммерческий, научный, и проект "для себя". Понятно, что проект "для себя" может легко стать научным или коммерческим. Многие продукты изначально имеют определенную направленность. Как пример научного проекта можно привести Algol 60. Языки С и С++ начинались как проекты "для себя" а потом впали в коммерческое русло. Java, как видим, изначально была коммерческим проектом, причем неясной ориентации. Она должна была приносить прибыль, но как - никто не знал. Пожалуй, лишь несколько человек могли бы заявить что они делали Oak "для себя" а не для доброго богатого дядюшки. Немудрено, что Java потребовала тех самых "дорогостоящих маркетинговых акций" для своего распространения. Многие скажут, что количество приложений на Java и без того достаточно велико. Я не стану спорить. Но понаблюдав за JavaSoft.com можно заметить заметим как быстро коммерциализуется все, что связано с Java. Под нее нет столь обширных, сколь и бесплатных средств как под С. Что ж - время бесплатных программ прошло (или еще не настало?), теперь главное - прибыль. Можно радоваться хотя бы тому, что само JDK отдается бесплатно. Надолго ли?

2.2. SUN и попытка прорыва в Internet.
К моменту создания Java, SUN (основанная в 1982 году) была крупной и уважаемой компанией. Ее рабочие станции и программное обеспечение было широко известно. SUN OS широко использовалась в сетях TCP/IP благодаря общей нацеленности компании на сетевые вычисления. Однако, в первых днях "революции WWW" SUN почти не участвовал. Странно, но факт. Только когда для Java не нашлось других достойных применений, было решено использовать ее в Internet. Здесь тоже часто происходит путаница. Взрывное развитие WWW и Java (видимо с легкой руки маркетойдов SUN) чуть ли не отождествляют. А это совсем не одно и тоже. Я уверен, что без Java, развитие сети замедлилось бы несущественно. Даже сейчас мы встречаем не так уж много сайтов, сильно ориентированных на Java. HTML по-прежнему остается важнейшим средством и развивается своим путем (вспомним XML). Столь часто отождествляют JavaScript и собственно Java. Первое - фактически часть browser-а, плотно интегрированная с HTML и имеющее с Java мало общего. (Если коротко охарактеризовать JavaScript - это просто C без строгой типизации и указателей, плюс объектная модель HTML, поддержанная в соответствующем browser-е). Второе - вполне самостоятельный язык, который слабо связан как с HTML так и с Browser-ом, и в идеале вообще обрабатывается JVM поставляемой вместе с используемой вами OS. Многие пользователи предпочитают просто отключить поддержку Java, дабы не ждать долгой загрузки аплетов и избежать проблем с безопасностью. Конечно есть еще и browser Hot-Java (написанный на Java и поставляемый SUN). Но процент людей использующих его очень мал по сравнению с NetScape и Internet Explorer. Конечно, удался ли прорыв Sun и Java в Internet судить еще рано, но на деле он не так велик как на словах.

2.3. Версии JDK - стадии развития.
2.3.1. Ранние версии.
Вернемся снова к нашей Java. Как известно, несмотря на то, что сам язык практически не менялся, существует несколько версий JDK (Java Development Kit - набор разработчика Java). Пожалуй, первая широко известная версия JDK - 1.02. В принципе - это уже рабочий инструмент. Конечно, в нем есть множество недоработок, но писать программы с его помощью можно. Что было плохо в JDK 1.02? Прежде всего - обработка событий. Убогая "событийная модель" мешала, нормально программировать приложения связанные с интерфейсами пользователя. В дальнейшем эта проблема была решена, но разрыв между JDK 1.02 и 1.1 так и сохранился по сей день. На этом примере мы видим первое подтверждение того, что хотя Java дает некую совместимость "в пространстве" (т.е. на разных платформах), она не гарантирует "совместимости во времени" (т.е. разных версий). В JDK 1.02 также не было Swing, RMI, и еще много чего. Я не будем больше обсуждать эту модель.

2.3.2. Первые полноценные версии.
"Нормальные" люди начали программировать уже на JDK 1.1. Это был неплохой продукт. Модель событий здесь достаточно гибкая, и вполне понятная. Хотя и тут все гладко. Конечно, новые функции были добавлены, но далеко не все, которые необходимы программисту. В версиях JDK около 1.1.5 уже имелась встроенная поддержка удаленного вызова методов (Remote Method Invocation - RMI) и средств взаимодействия с базами данных (Java DataBase Connectivity). (Без этого я вообще с трудом представляю программирование на Java). Но по-прежнему не было нормальных средств для симметричной криптографии, работы с брокерами запросов (ORB) и полноценной графической библиотеки. Тут уместно еще раз вспомнить, что Java задумывалась и позиционировалась SUN как средство для распределенных, сетевых вычислений. Но сетевые вычисления это нечто больше чем поддержка TCP/IP. Иначе, идеальным языком для них следовало бы признать С. Так вот, до появления RMI (которое, по сути есть давно известное Remote Procedure Call - RPC в Java оболочке) - средств распределенных вычислений в Java практически не было. Кстати, RMI также нельзя отнести к полноценным средствам. То же касается и графических возможностей Java. Как было указано выше, AWT, поставляемое вместе с JDK ранних версий поддерживает только примитивные графические объекты. К тому же, эти объекты по разному выглядят на разных платформах. Для решения этой проблемы была создана обширная графическая объектная библиотека Swing, которая базировалась лишь на рисовании примитивов (линий, точек) и обеспечивала поэтому одинаковый внешний вид на всех платформах. Хорошая проработка объектной модели позволила Swing быстро завоевать популярность, но ее применение все же было ограничено отсутствием нужных классов в JDK, немалым объемом и крайней медлительностью. Следует заметить, что большинство ранних версий JDK не имели в своем составе (Just in Time) JIT-компилятора, и поэтому их быстродействие было очень невелико. Среднее отставание обычного интерпретатора от JIT-компилятора составляет от 2 до 10 раз на разных задачах, что, согласитесь, немало.

2.3.3. Текущее состояние.
Совсем недавно вышла версия JDK 1.2 (или как ее еще называют Java 2). Это - самая полная (и самая громоздкая) версия JDK. В нее включены практически все пакеты, поставлявшиеся раньше отдельно, или отсутствовавшие вовсе. К радости писателей интерфейсов в JDK наконец-то включен Swing, улучшены средства AWT в области рендеринга и 2D-графики, появились средства симметричной криптографии, продвинута модель Java-Beans используемая для работы с компонентами в IDE средах, расширены средства RMI, и наконец - появилось то, что якобы было заложено в Java изначально - поддержка "вселенной свободно -живущих объектов" на различных платформах - средства CORBA.

2.3.4. Java и CORBA.
О CORBA (Common Object Request Broker Architecture - общая архитектура брокеров обьектных запросов) следует рассказать отдельно. Это архитектура довольно долго разрабатывалась консорциумом OMG, и в той или иной форме была реализована в нескольких продуктах. Необходимость создания языково-независимой (и платформенно-независимой) объектной модели стала ясна давно, как только появились сложные графические среды объединяющие в себе разнородные интерфейсы. Одной из первых это поняла фирма IBM, создав свою System Object Model (SOM) реализующую подмножество CORBA, и написав на ее базе "объектную" графическую оболочку для операционной системы OS/2. MicroSoft тоже не дремал, продвигая свою (как всегда "альтернативную") модель DCOM, которая была поддержана им в Windows/95/NT. Даже консервативные UNIX-ойды со временем поняли полезность объектных сред, и создали проект GNOME, который сейчас по темпам развития обходит такие "необъектные" проекты как CDE и KDE. И вот - в последнюю версию JDK включены средства CORBA. Но так ли все хорошо как кажется? Посмотрим на вопрос внимательней.

В рамках архитектуры CORBA, OMG предложил реализовать следующие сервисы: сервис именования, сервис событий, сервис поддержки "жизненного цикла", сервис устойчивых объектов, транзакционный сервис, сервис поддержки согласования, сервис отношений, сервис внешнего взаимодействия, сервис запросов, сервис лицензирования, сервис свойств, сервис службы времени, сервис секретности, сервис взаимодействия объектов и сервис группировки объектов. Итого - 15 различных сервисов, из которых в Java реализован собственно один - сервис именования (Naming Service). Понятно, что если cспецификации OMG дают программисту практически все необходимое, то о Java этого сказать нельзя. Скорее - это только базовые возможности которые позволяют установить соединение с каким либо другим ORB (Object Request Broker) и экспортировать/импортировать методы/объекты. Конечно, есть надежда, что поддержка CORBA в Java не будет стоять на месте. Кроме того, имеется множество других ORB, дающих гораздо больший набор сервисов. Из лидеров я бы отметил OrbixWeb фирмы Iona Technologies и VisiBroker от Inprise (бывший Borland). Но вот беда - ни один из указанных брокеров не совместим с Java, хотя все они (по спецификации) поддерживают один протокол. Так что пользователю придется выбирать между бедными возможностями "pure Java" и богатыми возможностями продуктов третьих фирм.

2.4. Составляющие коммерческого успеха.
Поговорим снова о "коммерческом успехе" продуктов. От чего он зависит? Имеется множество примеров когда лучшие по всем параметрам продукты не смогли завоевать рынок и уступили конкурентам, или даже были "похоронены" самой фирмой-разработчиком, уступив место менее качественным. Сторонники Java скажут что важна открытость и совместимость со стандартами. Но, как мы видим, это далеко не так. В противном случае трудно объяснить, как Microsoft Windows смог завоевать столь большую долю рынка OS. Можно считать что главное - дружественный интерфейс пользователя, но тогда программисты работали бы сейчас исключительно на Mac (кстати, JDK имеет лишь командно-строчный интерфейс). Технические новшества также не играют решающей роли, равно как и мощность средства. Что же делает продукт популярным, и более того - покупаемым? Как ни печально - в основном деньги, и как прямое продолжение их наличия - громкая реклама. Вспомним домохозяек, которые купили Windows'95 даже не имея компьютера, только потому, что "он позволит делать ту же работу что и раньше, но проще и быстрее". Нечто подобное наблюдается и с Java. Ее используют по делу и нет, даже в тех областях, где можно легко обойтись имеющимися средствами. Это и называется "Java завоевывает мир". Однако, не будем принижать Java. У нее есть несколько важных достоинств, о которых нельзя не упомянуть. Прежде всего - это обширные библиотеки, сравнимые разве что с библиотеками C. Последняя версия JDK действительно предоставля ет весьма широкий спектр функций практически на любой вкус. С этим напрямую связан и другой фактор - наличие стабильной поддержки. Вот две вещи которых не хватает многим freeware проектам. Поддержка SUN вселяет в сердца разработчиков и пользователей уверенность в надежности Java-way, и более того - направленности ее в завтрашний день (То есть если мы купим/используем Java сегодня, то этого не придется делать завтра!) Конечно, SUN поддерживает JDK всего для двух (причем коммерческих!) платформ - Windows и Solaris. Но многие компании уже лицензировали свои продукты, поэтому ареал Java не ограничивается этими двумя системами. С другой стороны, качественная поддержка имеется все же лишь для коммерческих OS. Оригинально поступил MicroSoft - не желая мириться с монополией SUN, он выпустил свою JVM (правда, слегка не совместимую с SUN), которая поставляется вместе с Windows, но этим, похоже лишь упрочил позиции Java. Итак, я в общих чертах обрисовал составляющие "коммерческого успеха". Надеюсь, меня не поняли превратно. Я вовсе не берусь утверждать, что высокоехнологичный, мощный продукт с хорошим интерфейсом и поддержкой не может завоевать рынок. Почему бы и нет? Просто в реальности все чаще победа остается за громоздкими, сырыми и малофункициональными продуктами поддержанными громкой рекламной компанией.

2.5. Java и browser-ы.
Уделим несколько строк поддержке Java browser-ами. Как я уже говорил, Java и JavaScript это "две большие разницы". JavaScript есть неотъемлемая часть browser-а интерпретируемая им. Java - другое дело. По большому счету лишь три browser-а поддерживают Java (последний - с оговорками). Это конечно же HotJava (его редко можно увидеть, но в он существует!), NetScape Communicator и Internet Explorer. Вы когда нибудь замечали за своим browser-ом странные замирания, когда в нижнем углу пишется таинственное "Starting Java..." а потом долго шуршит винчестер. Затем пишется о том что 1% из 1.2 Mb уже загружен, а через несколько минут выводится сообщение о недостатке виртуальной памяти и browser вылетает. Правильно, это и есть Java! (Просто какой-то любитель сделал свой аплет для показа текущего времени с помощью Swing, и вам пришлось качать всю библиотеку на свой компьютер из Америки). Я до сих пор еще помню, какое удовольствие получаешь запустив Netscape c включенной поддержкой Java на 16 Mb под Windows'95. Но не желаю вам таких воспоминаний. JVM browser-ов плоха не только своей прожорливостью, но и тем, что обычно слегка отстает от "текущей" версии JVM. В результате многим несчастным программистам до сих пор приходится писать на JDK 1.0.2 из за совместимости со старыми Browser-ами. Отдельную головную боль Java создает системным администраторам. Они знают сколько ошибок уже было найдено в реализациях JVM и вполне справедливо полагают что эти ошибки не были последними. С другой стороны - у встроенной JVM browser-ов есть и достоинства. Так, в них довольно рано появился пресловутый JIT - компиляция на лету. Поэтому они часто превосходят JVM ОС по быстродействию. Есть пожалуй единственный случай, когда Java в browser-е действительно необходима. Это случай сложного интерактивного общения с пользователем в реальном времени. Например - аплет для игры в тетрис. Здесь с полезностью Java вряд ли можно спорить.

2.6. Кросс-платформенность Java.
Обычно, именно кросс-платформенность Java является решительным аргументом при ее выборе. Действительно, если нам нужно чтобы приложение шло в UNIX-ах, мы напишем его на GCC. Но если нужно чтобы оно работало еще и в WindowsNT - остается Java. конечно, можно использовать #IFDEF (после чего программа вырастет вдвое), или написать приложение на Perl-е, но все это полумеры. Java - вот средство которое спасет вас. Конечно и там вы не сможете полностью абстрагироваться от ОС, но абстракция эта будет довольно хорошей. Другое дело что Java есть далеко не везде. Помимо Solaris и Windows я бы назвал операционные системы IBM (OS/2, AIX) и (уже в меньшей мере) Linux. Java доступна и на других платформах, но насколько качественно она там поддержана это еще вопрос. Часто удается перенести в какую либо OS Java-интерпретатор, но о таких вещах как JIT-компилятор остается только мечтать. Не будем при этом забывать, что разница в производительности их столь велика, что не может быть списана со счетов. Даже C++ часто оказывается недоступен для целевой платформы разработки. И тогда приходится как и 20 лет назад писать на обычном С. Со временем и эта ситуация возможно исправится, но доживет ли Java до этого светлого дня - непонятно. Ко всему сказанному надо различать кросс-платформенность "для программиста" и кросс-платформенность "для пользователя". Интересно, что пользователю кросс-платформенность даже не особо нужна. Пользователь обычно любит и использует одну систему и ему интересно чтобы хороший Soft был именно под нее. Более того, отсутствие/наличие этого самого soft-а под другую систему зачастую является предметом его гордости (или наоборот зависти). Пользователи не особо одобряют перенос своего любимого Soft-а на другие системы, видя в этом удар по своей. Разработчику, напротив, кросс-платформенность нужна, так как продав свой продукт большему числу пользователей он получит больше прибыли и охватит более широкий сектор рынка. В этом смысле - Java полезна именно разработчику, а не пользователю. Почти никто в Windows'95 не использует Java ICQ, ведь есть нативное! Это же можно сказать и о HotJava c NetScape. Вообще, проблемы с кросс-платформенностью часто настолько же надуманы, насколько и их решение. Ясно, что никто не мешает разным фирмам написать 10 компиляторов с Ada под 10 различных платформ, причем совместимых между собой. Но этого никто не делает. С другой стороны, можно сделать 10 несовместимых реализаций Java, сведя на нет все его достоинства (что и делает MicroSoft). (Ведь ясно что даже SUN не сможет написать JDK под все платформы). Дело здесь в том, что торговая марка Java принадлежит SUN, а реализации Java должны ей лицензироваться, и это сдерживает "несовместимость". Как видим - в дело опять вмешивается "большая политика".

3. Еще не смерть (близкое будущее).
Данный раздел будет посвящен тем "легким облачкам", которые появляются на горизонте Java (то есть проблемам связанным с ней) и альтернативным подходам как к Java, так и к задачам, для решения которых она создавалась.

3.1. Рост объемов.
Ни для кого не секрет, что объем используемых нами программ все время растет. Закон Паркинсона приведенный в статье Н.Вирта "Долой "жирные" программы" гласит, что "Программное обеспечение увеличивается в размерах до тех пор, пока не заполнит всю доступную на данный момент память". Также верно и замечание Вирта о том, что сложность программ растет гораздо медленнее потребляемых ресурсов. Все это в полной мере относится к Java. Объем последнего JDK составляет около 20 Mb в архиве, и еще больше на диске. Требования к быстродействию машины весьма высоки. Не легче чем машине, приходится программисту. Первый раз увидев документацию по Java он просто теряется перед таким объемом, и требуется много времени чтобы освоить хотя бы базовый набор функций Java. Я бы сказал, что на Java трудно начинать программировать. Даже после года работы с ней, я не могу выкинуть ссылку на документацию по JDK из своих BookMarks. Воистину, по необъятности Java приближается к таким монстрам как PL/1 или Visual C++.

3.2. Проблемы быстродействия (JIT, Java to Native)
Поистине, достижения инженеров проектирующих процессоры - единственная надежда для производителей программного обеспечения. Еще недавно 33 Mhz были пределом мечтаний, а сегодня никого не удивишь тремя стами. Для Java эта проблема стоит особенно остро (не будем забывать об интерпретации байт-кода). Именно поэтому усилия разработчиков сейчас все больше концентрируются на создании высокоскоростных JIT-компиляторов, и те, кому это уже удалось (IBM, SUN) считаются лидерами отрасли. JIT технология, однако, имеет серьезные недостатки, вполне осознаваемые большинством разработчиков. Понятно, что для качественной оптимизации нужно время, а как раз этого времени у JIT-компилятора нет. В отличии от нормального транслятора который один раз долго компилирует программу, чтобы потом она быстро выполнялась. В принципе, не так уж много барьеров мешает подойти к Java как к обычному языку программирования, то есть транслировать ее в исполняемые файлы. По этому пути пошли несколько фирм, в том числе и IBM (уже анонсировавшая создание такого компилятора и раздающая его бета-версии). Аналогичные разработки ведутся и в России, довольно известной фирмой XDS. Ясно, что пользователю конкретной системы именно это и нужно. Возможность запуска классов на других машинах его волнует меньше, чем быстродействие на своей. Другим путем (еще более простым) является статическая компиляция прямо из байт-кода в целевой код машины. Этим собственно и занимаются JIT-компиляторы, только "на лету" что конечно важно в Browser-ах, но совершенно не нужно для локальных приложений пользователя. Нам кажется, что в ближайшее время можно ожидать развития и этого направления. Еще один путь - это оптимизация уже имеющегося байт-кода для более быстрого исполнения. В этом направлении двигаются создатели такого пакета как DashO. IBM, похоже решившая стать крупнейшим производителем в области java, тоже делает шаги в этом направлении.

3.3. JAVA - язык или среда? Any to Java (NetRexx, ADA, JASMin)
Со временем, компьютерное сообщество все более понимает, что Java не столько язык, сколько среда. Внешнее представление программ не так уж важно, по сравнению с байт-кодом и библиотеками функций. Отсюда, расцветшее буйным цветом, и весьма, на наш взгляд, перспективное направление компиляции в байт-код. Собственно, Java тут вообще не причем. Создать разумный байт-код, и договориться о компиляции в него, можно было и 10 лет назад. Но этого не было сделано. Теперь - шансы куда как выше. Ясно, что в байт-код можно транслировать практически любой алголоподобный язык (хоть тот же Fortran или СOBOL (что и делается)). Это тем более легко, если язык объектно-ориентирован. Сейчас, количество языков компилируемых в байт-код уже перевалило через десяток, здесь и такие известные языки как ADA и COBOL, и менее известные, например NetRexx и Eiffel. Становится ясно, что никакого особого "языка сети" нет. Есть не более чем видоизмененный С++, с успехом заменяемый многими альтернативами. Чтобы не быть голословными, приведем пример на трех языках, делающий одну и ту же операцию: на Java, на NetRexx и на диалекте Java Assembler-а Jasmin.

Первым идет пример на NetRexx (языке разработанном IBM имеющем синтаксис сходный с Rexx)

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

Development Kit для Inferno имеется под такие ОС как Solaris, Irix и WindowsNT и доступен для использования. По каким-то причинам этот проект не рекламируется так широко как Java и пока находится в тени. Однако перспективность его представляется весьма высокой.

3.6. Java-процессоры - кому это нужно.
Как один их альтернативных способов повышения быстродействия Java, SUN видит в создании процессоров, которые будут обрабатывать собственно байт-код JVM. Считается, что так удастся не только выиграть в скорости выполнения приложений но и облегчить написание JDK. Тем не менее перспективность такого подхода кажется мне сомнительной. Я говорю даже не о том, что на это вряд ли пойдут "гиганты отрасли" (вроде того-же Intel) - это понятно. Неясно другое - как скажется зашивание Java в процессор на других не-Java приложениях? Мне кажется что не лучшим образом. Кроме того, печальные результаты создания Forth-процессоров должны настораживать. Единственный вариант видится таким - написать все ПО с нуля, причем прямо на Java. Такой подход возможен, но сколько времени потребуется на его реализацию сказать трудно. Мы видим как, SUN, Oracle и IBM вот уже не один год продвигают идею сетевого компьютера (NC) как компьютера будущего, но это не мешает Intel-у создавать все более мощные процессоры, а другим производителям "железа" - комплектующие к самым обычным PC. Вывод - Java-процессоры нужны, пожалуй, только SUN, да и то неясно насколько сильно.

3.7. Java и большие системы.
Язык (языковая среда) пригодный для нависания больших систем должен удовлетворять ряду требований, из которых я бы отметил: структурность, модульность, поддержку раздельной компиляции, средства документирования и контроля версий. Из них первые три обычно относят к языку, а два последних - к языковой среде. (Интересно, что С++ не удовлетворяет как минимум трем из этих требований, и его применение в создании больших обусловлено наличием мощных IDE, берущих на себя всю работу). Java - безусловно структурный и модульный язык, при этом поддерживающий раздельную компиляцию. В нем при добавлении или удалении метода (или публичной переменной) в определенном классе, не нужно перекомпилировать вызывающий класс. С другой стороны, я просто не смогу откомпилировать свой класс вызывающий методы из другого, если у меня нет собранного класса с вызываемыми методами. Для решения этой проблемы можно использовать так называемые интерфейсы. Они дают возможность создать "промежуточный уровень" между вызывающим и вызываемым методом. Имея интерфейс класса (фактически - описание типов параметров), я могу транслировать программу, не заботясь о том, что нужный мне метод пишут где-то в Америке. В JDK имеется также встроенное средство документирования, позволяющее на основе исходных текстов генерировать описание программы в виде .HTML-файлов. В Java отсутствует средство контроля версий, но некоторые существующие оболочки включают в себя такую возможность. Исходя из вышесказанного, следует отметить что Java более приспособлена к созданию больших комплексов, чем многие другие языки программирования.

4. Resume.
Итак, я подошли к концу изложения. Теперь придется в нескольких коротких фразах резюмировать свое отношение к феномену Java, и оценить его перспективность. Что есть Java: "укол в самое сердце Гейтса", язык для управления бытовой техникой, язык для сети Internet, или просто элемент гигантской рекламной компании SUN? Об этом - ниже.

4.1. Результирующее определение Java
Java - это современный алголоподобный, переносимый, объектно-ориентированный язык (точнее - среда), имеющий сильную поддержку и обширные библиотеки, который благодаря этому (а также хорошей рекламе) завоевал большую популярность, и получил широкое распространение, особенно в приложениях связанных с Internet. При этом он не содержит никаких выдающихся нововведений, делающих его несравнимым с другими языками, а скорее вбирает в себя положительные черты других языков, не выходя за средний уровень. На данный момент этот язык еще не устоялся, находясь по-прежнему в стадии становления. Его подлинное предназначение остается для нас неясным, но вскоре видимо проясниться. На данный момент Java еще нельзя считать языком пригодным для разработки больших систем (в отличии от С и С++ ), хотя его возможности в этом направлении довольно велики.

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