>Уже и Java совместима не на все 100% (честно говоря, для меня это новость).

Ну, какая-же это новость?
Без шуток: нельзя на полную совсместимость рассчитывать НИГДЕ

Для Киреева Александра:
По моему у Вас талант - отвечая на вопросы не отвечать на них :). Я ж попросил указать плюсы, а Вы вместо этого начали говорить о Windows... и искать аналогии моим вопросам. Кстати аналогии не совсем правильные, как мне кажется. Да, действительно, переход от DOS к Windows (обычная эволюция, DOS не использовала всех возможностей процессоров) доставил всем много хлопот, но плюсы, которые он дал, были настолько велики, что все проблемы показались, просто, ничем. Взять ,хотя-бы, тот факт, что Windows избавила программистов от головной боли из-за программирования различной аппаратуры. Я, когда писал под DOS на Pascal'е, использовал графический интерфейс (была у меня своя библиотека) поэтому точно знаю, как приходилось извращаться, чтоб прога работала на большинстве видеоадаптеров. Такие же проблемы были и с другой аппаратурой. А посмотрите на Windows, что Вы видите? Никаких забот с программированием аппаратуры нет (если ограничиваться "стандартной" (не удачное слово) аппаратурой). Windows вовсе не ограничивает возможности программировать аппаратуру, просто в ней все это делается драйверами, и если Вы хотите, что-то хитрое делать с портами, и им подобными вещами, пожалуйста - пишите драйвер. Еще одним плюсом можно назвать защищенность процессов друг о друга (это про NT). А на счет flat-модели памяти Вы не правы, Windows тут ни причем, она просто использует возможности процессора, чего не делала DOS. Плюсов Windows еще очень много, но не о них речь. Вы упомянули такой вопрос, как автоматическое управление памятью, и назвали это плюсом. Но я еще раз повторяю, что намного эффективнее управлять памятью вручную. Похоже речь снова о Windows. Windows позволяет для каждой нити, Вашего приложения, использовать собственную кучу, что может значительно повысить производительность приложения, особенно если оно является сервером. Да и другие возможности Windows, по управлению памятью, не менее полезны. Можно, например, страницы памяти помечать так, чтоб в случае обращения к ним система генерировала исключительную ситуацию (но это не ошибка, а предупреждение), в этом случае программа получает возможность мониторить определенную область памяти. Можно сделать, чтоб кусок памяти не сливался в своп и.т.д. и.т.п. Короче возможностей тьма. И это не говоря о нововведениях в области асинхронного ввода-вывода, о возможности использования т.н. портов завершения ввода-вывода и других полезных фич. Вот это реальные плюсы. Я конечно не утверждаю, что пользуюсь всеми ими, но подход "...у клиента процессор позволяет не оптимизировать прогу" (это, конечно, не Ваши слова, но подход Ваш) мне, лично, очень не нравится. Мощность процессоров и объемы памяти растут не для того, чтоб программисты забыли про оптимизацию программ, или может нам не использовать алгоритмы быстрой сортировки, а заменить их "методом пузырька" (медленно, зато головной боли ни какой, да к тому-же клиент и не поймет со своим 900'м).

"Самая прозаическая причина смены (или не смены) средства разработки - $$$ ". Что это значит? Вам за Java-приложения больше платят?

"как я уже писал, с развитием ООП и усложнением программ некоторые приложения на компилируемых языках становятся не меньшими монстрами."
Это как сказать. Видал я EXE'шки по 5Mb, да действительно не мало, но вот посмотрел на файлы JBuilder'а и нашел файл jbuilder.jar (я, правда, не знаю для чего он нужен) так он весит все ~13Mb. Кто тут монстр?

"Еще более жизненным примером для переносимости будет работа с БД - намного приятнее иметь возможность быстро переехать с Оракла на MS SQL или обратно."
У нас большой проект создан на Delphi, так при разработке возможность сменить базу данных была одной из основных. Он работает.

P.S.
Кажется договорились. Уже и Java совместима не на все 100% (честно говоря, для меня это новость). Как-же, Ваши клиенты, будут переезжать на другую платформу если нет 100% совместимости.

Сергей Тарасов:
>Это к жабе никакого отношения не имеет. Кроме того, Вы этим самым
>завяляете, что у вас практически нет хранимых процедур, то есть все
>работает на сервере приложений или клиенте. А это далеко не всегда
>хорошо.
При чем тут хранимые процедуры. Я говорю о том, что когда заказчик говорит "хочу на Оракле", а есть на MS SQL'е, Вам будет намного приятнее, если это получится быстро, даже если Ваше приложение не работает на максимальной возможной скорости. Закзчику, обычно не важно, что приложение может работать еще быстрее, если оно уже работает с приемлемой скоростью. А рассказывать ему о хранимых процедурах - что об стену горохом. "Я вас не просил о какой-то супер скорости - Вы не умеете делать программы" - вполне возможный его вывод.

Еще раз повторю, это - пример, кому-то он может помочь понять то, о чем я говорю, а Вы пытаетесь сделать вывод о том, как _я_ пишу программы. Если Вы считаете, что это плохой пример - скажите почему. Я хотел обратить внимание на пользу SQL, как стандарта для общения с базой, и реляционных баз вообще, как общепринятой структуры БД, а вы съезжаете на проблемы совместимости БД.

>Еще более жизненным примером для переносимости будет работа с БД - намного приятнее иметь возможность быстро переехать с Оракла на MS SQL или обратно
Это к жабе никакого отношения не имеет. Кроме того, Вы этим самым завяляете, что у вас практически нет хранимых процедур, то есть все работает на сервере приложений или клиенте. А это далеко не всегда хорошо.

Казанцев Алексей:
Самая прозаическая причина смены (или не смены) средства разработки - $$$ ;-) Другой вопрос - нравится ли людям их средство разработки. Мне жаба нравится, поэтому я о ней пытаюсь рассказывать.

Теперь пора вернуться к баранам.

Начнем со скорости. Для тех приложений на жабе, которые я видел, производительности современных машин вполне хватает (как мы все теперь, благодаря Вам, знаем, ее хватает не всегда, но в подавляющем большинстве случаев). Несмотря на более низкую скорость работы, программы на жабе вполне могут обеспечить достаточную для пользователя скорость обработки его запросов (т.н. "interactive real-time"). Если посмотреть на уровень загрузки прцессора при работе _пользователя_ с приложением на Delphi/C++ - он не поднимется выше 30%, думаю, даже на P200, а Вы, например (сами говорили), работаете на 900. В эти 70% вполне помещается жаба со всеми потрохами (причем, хвала Сану, с каждой версией, все лучше). На сервере (или при выполнении неинтерактивных действий), конечно, все не так просто, но, как я уже писал, с развитием ООП и усложнением программ некоторые приложения на компилируемых языках становятся не меньшими монстрами.

Первое, что приходит в голову в качестве аналогии к вашим вопросам - появление Windows вместо DOS. Было очень много похожего - повышение требований к памяти, к процессору, невозможность прямого доступа к аппаратным ресурсам и т.п. Наверняка были способы улучшить производительность программы на Паскале, путем правильной и своевременной загрузки оверлеев. Но какими усилиями это давалось. Сколько проблем сняла flat модель памяти, ставшая де-факто стандартом в Windows. Этот же пример работает и к вопросу использования особенностей ОС - вы же не пытаетесь в своих приложениях командовать системе, что надо свопить, а что кэшировать. В жабе есть аналогичный плюс - автоматическое управление памятью. Где плюс? Дело в том, что благодаря автоматическому управлению памятью jvm точно знает где и что выделено, какие есть ссылки и имеет возможность делать с памятью все, что хочет (отсутствие указателей очень помогает). В том числе и правильно распределять выделенную память (компактность хранения данных в памяти, locality of reference). Если интересно, можете почитать о приципах работы сборщиков мусора (современных) - могу ссылочки поискать. И заметьте, что разработчики на жабе все это получают бесплатно (с последней hotspot jvm от Сана) даже не видев книгу о системном программировании под Win2k, Солярис или Линукс.

Теперь об ошибках. Я не случайно об этом вспомнил: программа, конечно, не должна содержать ошибок, но только тогда, когда мы ее закончили. Лично я большую часть времени провожу за разработкой/поддержкой продукта, то есть, когда программа еще не готова, а значит может содержать ошибки. Вот и пригождается возможность их легко обработать (особенно, если ошибки не мои ;-) ) И потом, все равно все глюки не отловишь (а если еще пользователь издеваться над программой начнет).

Насчет переносимости опять приведу в качестве примера Windows: регулярно встречаются программы "только для 9х" или "только NT/200", а сколько фрагментов if (os == win9x) мы еще не видим. То же самое и с жабой - 100% переносимости нет, но она максимально облегчена. А клиентов иногда радует сам факт того, что при желании можно будет переехать на другую платформу. Еще более жизненным примером для переносимости будет работа с БД - намного приятнее иметь возможность быстро переехать с Оракла на MS SQL или обратно.

Ну все, рука бойца колоть устала. И вообще, работать пора ;-)

Для Александра Киреева:
Спасибо за такой полный ответ (хоть и не очень конкретный;), но Вы, наверное, меня не правильно поняли - я не собираюсь переходить на Java. Мне просто интересно, что заставляет людей менять средства разработки, причем переходя на далеко не лучшие (с моей точки зрения). Переходя на Java, скажем с Delphi или C++ Builder'а, мы, однозначно, теряем в скорости выполнения приложений. Теряем возможность использовать особенности конкретной ОС, но если используем их то теряем переносимость. Теперь имеет смысл затронуть необходимость использования, этих самых, особенностей. Я недавно приобрел книгу "Системное программирование в Windows 2000", не скажу, что книга супер, но там хорошо объясняется, как управляя таким процессом, как выделение памяти, можно увеличить (в несколько раз) скорость приложения. А если Java абстрагируется от ОС то значит она не может учитывать всех тонкостей (виртуальная машина тут не поможет т.к. она не знает чего хочет программа). Следовательно она теряет производительность даже на этом (не говоря об интерпретации и.т.п.). Не знаю, как Вы, но я вижу в этом переходе только минусы. А разговоры о том, что "...максимальным наказанием будет Exception (NullPointer, ClassCast и т.п.), а следовательно большая часть программы может работать, не обращая внимания на отдельные, пусть даже серьезные, ошибки." это все слова, хорошая программа не должна содержать серьезных ошибок. В конце-концов все зависит от программиста. Не сочтите это за наезды на Java или Вас лично, просто я не вижу явных плюсов, которые погасили-бы все эти минусы. А удобство разработки приложений в разных среда это дело вкуса. И выбор языка личное дело каждого. Что лично Вас заставило перейти с Си на Java и использовать Java в качестве основного средства при разработке приложений? Зачам Вашим клиентам Java приложения? Им нужна переносимость? Если не нужна, тогда объясните смысл перехода на Java.

Казанцев Алексей:
>1. Вы пишите, что давно работате с Java.
Давно с жабой вряд ли кто-то работает, но в последнее время я с ней работаю, скажем так, "усиленно".

>Меня интересует (если это не секрет), приложения какого рода Вы
>разрабатываете на Java, и кто ими пользуется. А так-же хотелось бы
>узнать на каком "железе" они работают и каковы отзывы пользователей.
Приложения, естественно, сетевые. Обычная схема: клиент-application server-база. Пользователи разные - ограничения на железо тоже бывают, но редко, и, в основном, железо на уровне (память 64+, процессоры не меньше 200МГц). Если жалуются - исправляем ;-)

>Как пользователи относятся к интерфейсу, который не совсем гладко
>имитирует ту-же Windows, или их это не беспокоит?
Если постараться (усилия нужны не очень большие и одноразовые - легко повторно изпользовать), то отличия от Windows - минимальные и жаловаться просто не на что. Swing эдесь очень помогает: как уже писали, в нем можно настроить практически все.

>2. Если Java является переносимой системой, зачем нужна JavaOS?
>Неужели только для того, чтоб показать всю "круть" использования
>Java? Каковы реальные плюсы?
Я еще не разбирался с jos (ссылочка тут была), но могу предложить несколько аспектов, в которых JavaOS могла бы помочь.
1. Лишний уровень абстракции - многие операции jvm делегирует к ОС в абстрактном смысле, а та, к своим драйверам. JavaOS может сократить этот путь. Например обращение к дисковому кэшу "внутри jvm" существенно быстрее, чем несколько раз лазить через шлюз jvm-OS.
2. Общие ресурсы. Каждая jvm работает со своим набором классов - даже стандартная библиотека не разделяется - это одна из причин прожорилвости жабы в области памяти. То же относится и к скомпилированному коду: вышел-зашел - все заново компилировать.

>3. В чем разработка Java-приложений быстрее разработки Delphi/C++
>Builder приложений?
А вот это - провокационный вопрос ;-) Разворачивать теорию не буду - расскажу, что мне нравится.
1. Устойчивость. Даже если я откровенно расслабился максимальным наказанием будет Exception (NullPointer, ClassCast и т.п.), а следовательно большая часть программы может работать, не обращая внимания на отдельные, пусть даже серьезные, ошибки.
2. Ясность языка. Никаких множественных или protected наследовний, но, вместе с тем, строгая типизация. Чего только одни интерфейсы стоят. А из ясности следует, что хороший дизайн легче превратить в хорошую реализацию.
3. Продуманная библиотека. Стандартные средства (от Сан'а) позволяют делать столько всего... И расширяемость/модифицируемость очень легко дается. Соответственно третим производителям (напрмер Борланду) легче сосредоточится на создании расширений, вместо попыток организовать имеющиеся возможности в нормальную библиотеку.

В общем пробуйте. Когда я начал учить жабу, я называл ее не иначе, как "кастрированный С++". Недавно я скрещивал программу на С++ с жабой: сначала я удивлялся, как можно на _этом_ писать (это Lamer'у, насчет работы со строками), а потом хороший кусок функциональности, который предполагался на С был сделан на жабе (сократив время на отладку и написание).

Disclaimer: не ищите в этом сообщении наезды на другие языки/системы - их тут нет ;-)

Для Александра Киреева:
1. Вы пишите, что давно работате с Java. Меня интересует (если это не секрет), приложения какого рода Вы разрабатываете на Java, и кто ими пользуется. А так-же хотелось бы узнать на каком "железе" они работают и каковы отзывы пользователей. Как пользователи относятся к интерфейсу, который не совсем гладко имитирует ту-же Windows, или их это не беспокоит?

2. Если Java является переносимой системой, зачем нужна JavaOS? Неужели только для того, чтоб показать всю "круть" использования Java? Каковы реальные плюсы?

3. В чем разработка Java-приложений быстрее разработки Delphi/C++ Builder приложений?

Казанцев Алексей:
>Запустил. И что? Проц грузится на все 100%. Уже заметны рывки при >отрисовке анимации. <...> С чем это связано я не знаю, вроде ничего
>другого не запускал и ничего страшного не делал.
Есть вероятность, что Винда помогла, а вообще, Java2D разрабатывалась скорее для удобства программирования чем для производительности - надеюсь, Вы обратили внимание на качество.

>Еще одна интересная деталь, монитор расхода памяти показывал
>примерно 15 мегабайт Allocated и 7-14 мегабайт Used, а Task Manager
>показывал, что JVM пожирает раза в 3-3.5 больше. Чем это
>объясняется?
Монитор показывает только heap - о jvm программа не знает (вдруг под JavaOS запустят).

>И мне кажется, что эта демка будет жутко тормозить на "слабеньких" (PII-350 и ниже) машинах, <...>
Не совсем так. Пробовал на К6-206, 64М - смотреть все еще можно. Это, кажется, является показателем, что узкое место находится по пути от jvm через винду на экран, но утверждать не буду - с жабой всю производительность можно оценивать только по реальным тестам - умозрительные рассуждения слишком часто подводят.

>А если Вы говорите, что работу в Windows нельзя считать показателем,
>то у меня вопрос: сколько Linux-станций работает у Вас или Ваших
>клиентов? У нас только одна. И та экспериментальная.
Работа в Windows, имхо, главный показатель (коммерческой) применимости системы, а на Linux'e можно посмотреть возможности технологии. Технология, кстати, не совсем для нас: буржуи ее для себя делали - им намного дешевле купить мощное железо, чем программистам платить, а разработка на жабе очень быстро идет.

Для Tony (№159):
Я посмотрел дома демку (Java2D) о которой Вы писали. Запускал из под JVM. Скорость отрисовки вполне приличная, ну еще-бы проц-то 900MHz. Task Manager показывал загрузку процессора 50-80%. В общем был заинтересован увиденным. Сегодня пришел на работу и попробовал запустить эту демку на PIII-500MHz. Запустил. И что? Проц грузится на все 100%. Уже заметны рывки при отрисовке анимации. На закладке Mix, прыгающие шарики время от времени умирали секунды на 3 затем рывок и снова умирали. Такая-же картина наблюдалась и с панелью, где есть прокрутка текста+полигон+дюк на кнопке. Звук иногда заикается. С чем это связано я не знаю, вроде ничего другого не запускал и ничего страшного не делал. Еще одна интересная деталь, монитор расхода памяти показывал примерно 15 мегабайт Allocated и 7-14 мегабайт Used, а Task Manager показывал, что JVM пожирает раза в 3-3.5 больше. Чем это объясняется? И мне кажется, что эта демка будет жутко тормозить на "слабеньких" (PII-350 и ниже) машинах, к сожалению не имею возможности попробовать (не бежать же в бухгалтерию на P133). Кстати PII-350/64Mb у нас используется в качестве резервного SQL сервера, а i486DX2-66 с оперативкой 16Mb работают в некоторых цехах, в качестве клиентских станций для работы с программой табельного учета (MIDAS,Delphi). А если Вы говорите, что работу в Windows нельзя считать показателем, то у меня вопрос: сколько Linux-станций работает у Вас или Ваших клиентов? У нас только одна. И та экспериментальная.