2006-08-13

Что мешает Java-счастью. Взгляд со стороны.

Я не являюсь Java разработчиком, можно сказать, что я присматриваюсь.
На текущий момент есть всего две альтернативы Java или .NET.
Мне верится, что "правда" за свободным сообществом Java разработчиков.
Небольшое изучение вопроса показало его (общества, Java) болевые точки.
Буду рад, если кто-то более знающий прокомментирует мои наблюдения.

1. Разброд в рядах. Та же самая болезнь, которая вредит unix/linux/остальным подобным проектам. Конкурент - Microsoft - монолитен, согласован и напоминает шеренгу спартанцев.
В рядах же не-Microsoft разработчиков беснуется Новодворская Ричард Столман, тянут в разные стороны разобщенные группы фанатов PHP, C, Python, Perl и т.д., развивается кукушонок Mono.
На заре "раздела мира" похожая ситуация, когда производители UNIX, существенно превосходивших DOS-Windows, воевали между собой – привела к победе Microsoft.
Наиболее опасным я считаю две вещи:
1) Отсутствие Java доминирования. Заслуга Microsoft в том, что там поняли, как важно иметь ОДИН язык разработки (пусть вас не смущает рекламная шелуха про любые языки на .NET – фактически язык один C#). Из бытовых примеров правильности такого подхода мы видим Английский Язык (до развала СССР ещё Русский Язык). Когда люди ДУМАЮТ на одном языке – количество переходит в качество. Снижаются накладные расходы на переводчиков, издание книг об одном и том же на разных языках, люди более коммуникабельны и т.д. Microsoft жестко и даже с потерей доходов указало фанатам C++, а особенно VB – что их место у параши. "Или учишь C# или остаешься разработчиком второго сорта". В другом же лагере махровым цветом цветут С-сектанты и куча мелких языковых народностей.
2) Mono - проект кукушонок или для желающих троянский конь. Как некогда на заседание антимонопольного суда представитель Microsoft пришел с дистрибутивом Linux, так и Mono является такой же обманкой кросс-платформенности .NET. Рассмотрим живой пример: менеджер нового проекта решает, на чем вести разработку: Linux+Mono+Delphi.Net или Microsoft Windows+.NET+C#. Linux+Mono+Delphi.Net прекрасны, функциональны и открыты, но они вторичны. Менеджеру не нужны будущие потенциальные проблемы несовместимости с новыми версиями .NET. Никто не знает Microsoft лучше Microsoft. Если вы считаете, что пример надуман – вспомните odbc, ole db, ado, ado.net или VB vs Delphi. Всем людям с нормальной психикой было ясно, что Delphi в разы превосходит убогий чудовищный VB, тем не менее, сформирован огромный лагерь умственно отсталых VB разработчиков, которые даже любят это убожество.
Вывод: в качестве решения вижу создание крепкой дружной коалиции, в лице коммерческих организаций (Google, Sun, IBM, Oracle) и open source разработчиков (Linux, Apache, Open Office, Mozilla) выступающих единым фронтом, с единым мнением и комплексными интегрированными решениями: Linux+Java+Web.

2. Оптимизация быстродействия и требования к ресурсам.
Эта тема чрезвычайно интересна тем, что мнения по ней сугубо полярны.
Java разработчики: "программы на Java работают ничуть не медленнее, чем программы на C++/Delphi, а зачастую даже быстрее. Требования к ресурсам у них минимальны".
Пользователи Java разработок: "все безумно тормозит и жрет уйму ресурсов".
Небольшой поиск в Internet приносит материалы (охотно поверю, что рекламные) о том, что .NET приложения быстрее, чем приложения на Java.
Мне кажется, что сообществу Java/Sun/IBM следует привлечь хороших специалистов двух типов:
a) по оптимизации кода, менеджерам памяти и т.д.
b) по маркетингу и PR ;-)
Вывод: всегда есть, что улучшить! Вот горячий пример этого года: fastmm.sf.net – менеджер памяти для Delphi/BCB ускоряющий работу программ в РАЗЫ.

3. Интерфейс пользователя.
Больной вопрос, поскольку Java выросла из UNIX мира, где интерфейсы рисуют студенты второкурсники с гипертрофированной манией величия и отсутствием вкуса. Сейчас ситуация улучшается и desktop приложения на Java уже выглядят как плохенькие Windows приложения, но нельзя на этом останавливаться. Без завоевания Desktop все остальные победы временные. Любимый пример Java-разработчиков в таких случаях Borland JBuilder. Безусловно, отличная IDE! Недостижимый для большинства Java-разработчиков идеал, но начинающий разработчик на Delphi сделает такую IDE (без функционала, конечно :-) за несколько часов.
Вывод: поскольку Windows занимает доминирующие позиции на Desktop, и пользователи избалованы стильным дизайном от Microsoft – красивый стильный GUI для Java приложения должен стать не достижением, а нормой (видно что разработчики OpenOffice это поняли и результат не замедлил сказаться).

4. Кросс-платформенность в ширь и в глубь.
"В ширь" - означает большее количество платформ доступных по умолчанию.
Наиболее кричащий пример Pocket PC. Если для коммуникаторов на борту идет какая-то х.з J2ME, то для остальных ситуация просто удручающая. Нужно срочно исправлять положение: для мощных КПК разработать стандартную J2SE, для слабых/мобильных стандартную J2ME.

"В глубь" легче пояснить шуткой про Амфибию, которая плохая лодка и плохой автомобиль. Кросс-платформенность не должна означать, что на всех платформах программа работает одинаково плохо ;-)
На вскидку два примера:
1) "как запустить это чертово Java приложение". Я скачал и установил у себя свежий JRE, но ни .class файлы, ни .jar файлы не запускаются по клику. От запуска программ строкой в Command Line вида "java -ClassPath . bla.bla.bla" надо уходить, на дворе не 1980 год! (да, да, да! JBuilder запускается по клику – возьмите с полки пирожок).

2) Java daemon под Windows (NT service). Я не нашел простого быстрого способа запустить приложение на Java как сервис. Имеется в виду не только "запуск", но и получение и обработка событий suspend, resume, stop, а также работа с EventLog.
Это совершенно нормальные требования и если отмахиваться от них, то Java так и останется чем-то далеким и пугающим.
Вывод: расти в ширь и в глубь, не слушать крики "а нас все устраивает, у нас связка Oracle+Tomcat+IE" т.е. основательно идти на PDA и Desktop.

PS: Если кто-то говорит Java, .NET какая разница – мы на всем пишем. Знайте перед вами типичная "амфибия" ;-)
Настоящий профессионализм подразумевает многолетнюю практику, когда человек думает на языке и в терминах используемой библиотеки классов.
Любой Job-сайт показывает, что на должность простого кодера требуют 2 года опыта, архитектора до 5 и выше.