А зачем?

>>Так-же как и твоё право сделать форк, если этим недоволен.

А потом твоему форку не дадут лицензию о совместимости, даже если он ?>будет крут и совместим.

А зачем лицензия о совместимости? Главное чтоб работало.

и жрёт немеряно памяти.

Сколько и какого уровня ПО?
При цене 2GB памяти в $38 это становится смешно.

Для сравнения, вспомните, сколько стоил simm в 8mb и почему тогда было необходимо (!) писать на c, а лучше - на asm (как минимум вставками).

А давно вы видели Си-программу, которая _раз за разом_ перекомпилировала свои библиотеки?

Не видел. Но и в яве такой эффект наблюдается дай-бог первые сутки работы. Для десктопа конечно ничего хорошего, а для сервера вполне приемлемо.

P.S. я не призываю писать всё на Си++, но выкрики из серии «давайте всё писать на Яве!!111» от местных аналитиков идут на йух.

Ну так я тоже не призываю писать все на жабе, хоть и 90% кода что мне приходится писать по работе на нее родимую приходится.

Ява хороша для высоконадежных под нагрузкой масштабируемых приложений. И для довольно узкого круга десктопных задач. И не надо ее пихать во все щели.

>Для сравнения, вспомните, сколько стоил simm в 8mb и почему тогда было необходимо (!) писать на c, а лучше - на asm (как минимум вставками).

не надо ля-ля. Писали и на Basic, и на Pascal и все шло на 8mb + Windows 3.1

не надо ля-ля. Писали и на Basic, и на Pascal и все шло на 8mb + Windows 3.1

«hello world!» писали.

И вот пришел win95/nt4 написанный отнюдь не на basic и pascal и что, много ли можно было под ним приложений запустить имея в запасе <$40?

И быстрей ли текущей явы оно работало?

4 слота по 2 гига — это всего 8 гигов. на жирных проектах при увеличении кол-ва коннектов жаба и больше сожрёт. кстати, всегда оставалось загадкой, зачем этому монстру столько памяти.

А зачем лицензия о совместимости? Главное чтоб работало.

Если не совместимо - завалят исками по патентам. Условия GPLv2 это позволяют... А официальные тесты на совместимость не дают. Такие вот красавцы, они в частности и амеры вообще...

> Дорогая нынче энергия, да

500-ватный сервер за год отожрет электроэнергии по розничным ценам в россии примерно на $400

так что стоимость электроэнергии за срок службы примерно равна стоимости самого сервера

>«hello world!» писали.

под Windows 3.x был Visual Basic. А на Windows 95 c 16 mb Visual Basic 5.0 крутился шустро

на жирных проектах при увеличении кол-ва коннектов жаба и больше сожрёт.

Не надо тут этого пустозвонства. На каких и сколько?

c 16 mb

Visual Basic 5.0 крутился шустро

1) Цена 16mb во время VB5
2) Официальные минимальные системные требования в студию.

Для идиотов, напоминаю. Средненький банковский сервер стоит примерно $300K..$400K. Если ты вдруг захочешь просадить его производительность в 5-6 раз, для того чтобы позволить кодерам на Java потешить их раздутое ЧСВ, а потом компенсировать производительность увеличением мощности в 5-6 раз.. Ну, вы поняли..

А насчет сомнительности.. Java тормозила всегда. Она тормозила вчера, тормозит сегодня, и будет тормозить завтра. И аргумент про супержелезо завтра мы уже слышали в течение всего времени существования Java. Поэтому на серьезных задачах Java и не используется.

Java тормозила всегда.

Ага, а теперь убеди их, что java тормозит.

для идиотов напомню, что если раздутое ЧСВ С++ программиста уронит банковский сервер, потери могут быть намного больше.

баланс в общем нужен - где-то допустимо использовать неуправляемые языки, а где-то надо это делать с осторожностью (да, я знаю что инвест банки много делают на С++, они же много делают и на Java/C#)

Я приводил примеры двух серверов сообщений на Java, BEA и ActiveMQ. Вроде подходит под твое описание, 'высоконадежных под нагрузкой масштабируемых приложений'. BEA тратит более 1ms на сообщение, ActiveMQ - около 250mcs. Мы не смогли считать BEA сервером - слишком медленно работает для наших задач, поэтому обратили надежды к ActiveMQ. Посылаем 7000 сообщений и пробуем их считать - нормально. А вот 7200 и выше - оно умирает. Покажите мне сервер сообщений на Java, и я на него посмотрю.

А пока мы потратили 2 чел/мес, и написали свой на C++. Спокойно пропускает в тестах до 5M сообщений (можно и больше, но надо больше памяти. Скорость передачи сообщения в persistent mode - 76 mcs, почти вчетверо быстрее чем в ActiveMQ, и 18 mcs - в non-persistent mode.

А теперь, защитники Java, обьясните мне, почему программирование на C++ вы считаете медленным, а программы на Java - быстрыми и надежными?

А зачем мне их убеждать? Тесты интересуют только тестировщиков. Покажи мне быстрый Web-server, быструю СУБД, быстрый сервер сообщений - на Java. При этом желательно сравнивать на реальном железе. Скажем, на 4х ядерной машинке с 8Gb, так чтобы можно было проверить твои утверждения.

> А теперь, защитники Java, обьясните мне, почему программирование на C++ вы считаете медленным, а программы на Java - быстрыми и надежными?

Ай да белка, всех жаболюбов уел! :) Молоток, держи краба. ;)

То есть, ты решил, что раз на одной задаче java оказалась медленнее, значит она всегда тормозила, тормозит и будет тормозить? Гениально.

Web-server, быструю СУБД, быстрый сервер сообщений - на Java.

Выше разговор шел только про сервер сообщений... Тем более, никто не говорил, что СУБД на java будет быстрой.

Приведи пример быстрых web-сервера и сервера сообщений на c++, которые обладают такой же функциональностью и масшабируемостью как и java-овские сервера.

> Дело в том, что стоимость электроэнергии становится очень весомым фактором, а чем энергопотребление железа, сами понимаете...

гуглите «альтернативные источники энергии». Да и вообще: ближайшие 50-60 лет существенных изменений в существующей энергетической модели не видится. Технологии гораздо быстрее развиваются.

Уверяю вас, времена, когда большинство серверов будут запускаться на виртуальных машинах - очень недалеки, можно сказать, что для «передового форпоста» IT они уже давно начались

Не вижу противоречий: сервера на виртуальных машинах, на которых крутится все тот же JVM.

> модульные тесты писать на готовый и рабочий код - есть прямая потеря времени (если интересно, могу расписать подробнее)

Расписывай.

начнём с банального:

• очевидно, что суммарный выигрыш от применения модульных тестов должен быть больше, чем затраты на их создание и поддержание в актуальном состоянии
• модульные тесты никоим образом не заменяют функциональные, приёмочные, интеграционные и пр., хотя и могут использоваться для оценки регрессий

смысл написания модульных тестов (в рамках TDD) состоит в том чтобы дать разработчику:

• уверенность в том что твой кусок кода работает и работает правильно
• взгляд со стороны пользователя кода на интерфейс данного конкретного участка кода
• возможность быстро исправлять ошибки, связанные с добавлением новой функциональности (и рефакторинга), т.к. на данном этапе стоимость такого исправления на порядки меньше чем на этапе уже функционального тестирования

ну и до кучи: если тесты получаются корявые - это скорее всего пахнет bad design системы :)

соответственно, если код написан и работает - написание модульных тестов бесполезно (и даже вредно) по следующим причинам:

• написание в данных условиях модульных тестов - подгонка решения под ответ, практическая ценность данного подхода сильно снижается
• дублирование функционального тестирования
• потеря значительного количества времени

в общем всё просто: модульное тестирование банально не отбивается по затраченным ресурсам, а сами тесты получаются некорректные и не очень пригодные для дальнейшего использования по причине их «притянутости за уши»

Так что с позиции программиста Java - это удобный инструмент

С позиции пользователя - компромисс, приносящий в жертву его удобство и во многом - его деньги (учитывая повышенные требования к железу

наоборот, экономящий его деньги и сильно, Вы хоть представляете сколько стоит поддержка и сопровождение проекта, например, на С++ по сравнению с Java? да там на разнице любое железо сольёт по стоимости, причём с запасом

наверное, потому что быдло-кодерам, не понимающим разницу между managed языками (и решениями на их базе) и чем-то лепленным на коленке на cpp, надо в первую очередь интересоваться вопросами конфигурирования и оптимизации покупаемых решений + необходимых конфигураций железа для требуемого времени отклика/количества транз/сек и т.п., а не плакаться потом, что они не знали, что все так оно непредсказуемо. а чтобы не

кодерам на Java потешить их раздутое ЧСВ

надо понимать, какого уровня специалистов/суппорт вы берете на проекты такого масштаба.

что касается железа, никто какбэ не говорит, что если заменить те же спарки с высоким уровнем параллельности и отработки I/O-запросов на относительно бюджетное на х86_64, то получим ту же шоколадку, но за меньшие деньги ? указанные $300K..$400K в данном случае мало что говорят о деталях конфигурации (кстати, с учетом откатов сумма или как ?).

Мы не смогли считать BEA сервером - слишком медленно работает для >наших задач, поэтому обратили надежды к ActiveMQ. Посылаем 7000 >сообщений и пробуем их считать - нормально. А вот 7200 и выше - оно >умирает. Покажите мне сервер сообщений на Java, и я на него посмотрю.

А вы не интересовались (или может быть консультировались с разработчиками) в чем собственно проблемы - пулы ресурсов исчерпываются, I/O-перегружен, проблемы с память и т.д. ?

А пока мы потратили 2 чел/мес, и написали свой на C++.

Извините, но слабо верится, что ваше решение аналогично указанным по масштабу и надежности. Банально - работает быстро и «пока без сбоев», о расширяемости и масштабируемости молчим (банально больше памяти как бэ намекает, что для хранения используются in-memory структуры, а для указанных не-серверов тип и конфигурация хранилища сообщений не указаны), но не более того.

все разумеется глубоко имхо...

А пока мы потратили 2 чел/мес, и написали свой на C++. Спокойно пропускает в тестах до 5M сообщений (можно и больше, но надо больше памяти....

За какой отрезок времени?

Что используется в качестве persistent хранилища данных? Слабо верится что sql субд с поддержкой failsafe recovery.

Что будет с сообщениями если я выдерну шнур питания из сервака или долбану молотком по cpu?

Вы пробовали свой наколеночный сервак (под свои требования) написать на жабе? Или попробовали пару продуктов и с чего-то сделали вывод что жаба тормоз?

Итак, что мы имеем.

• BEA
• ActiveMQ
• Самописный глючный костыль на С++ с сомнительной надежностью и 0.001 фунциональностью от BEA, ActiveMQ

Где вариант

• Самописный глючный костыль на Java с сомнительной надежностью и 0.001 фунциональностью от BEA, ActiveMQ

Тогда было бы адекватное сравнение производительности

в. Покажи мне быстрый Web-server, быструю СУБД, быстрый сервер сообщений - на Java.

Интерестно бы Tomcat потестить. Думаю его обгонит только Apache, да и то на статических файлах.

Относительно СУБД не могу судить. Просто сейчас работаю со встраиваемыми БД. H2 загнала гектар блобов в базу почти со скоростью записи этих блобов просто в файл. Причем построила еще индекс. Поиск на уровне 1 мс. Pure-java, 1 MB jar, маленький обьем памяти, пока поддерживала все что нужно было. Интерестно, уделывает ли она SQLite? Разрабы не тестировали, так как в JDBC драйвере к SQLite нет транзакций.

Спокойно пропускает в тестах до 5M сообщений

Со скольки хостов слали сообщения? С тысячи хостов держит (в суме 5М)?

>гуглите «альтернативные источники энергии»
Угу. Я эколог по образованию и в отличие от вас прекрасно знаю, какова цена этим вашим альтернативным источникам и почему они сейчас используются на доли процента.
Если не считать атомной энергетики, с которой больше проблем, чем профита, если масштабы малы, то единственным реальным альтернативным источником сейчас является биоэнергетика, то есть в упрощённом понимании обывателя - дрова-навоз-метан.
Если бы энергетика использовала альтернативные источники хотя бы на 20-30 процентов, вы бы уже давно всю зарплату отдавали на электричество и отопление и ещё бы в долгу оставались при этом.
И мне неприятно это вам говорить, но технологии не успевают за ростом энергопотребления и в ближайшем обозримом будущем ситуация будет контролироваться только повышением энерготарифов и никак иначе. Проще говоря, вы будете либо меньше тратить на мощные сервера для Java приложений и юзать виртуалки, которые Ява плохо тянут, но могут потянуть оптимизированные для конкретной платформы и конкретной архитектуры, не зажатые искуственными требованиями к проектированию приложения на Си, либо будете больше платить.
Кстати, общемировая практика налоговых льгот для энергетически эффективных предприятий скоро докатится и до нас (в урезанном виде уже есть, кстати), только это будет по сути не льготами для тех, кто экономно расходует энергию, а повышенными налогами для тех, кто до сих пор живёт на широкую ногу.

>А теперь, защитники Java, обьясните мне, почему программирование на C++ вы считаете медленным, а программы на Java - быстрыми и надежными

А ты написал AMQP совместимый? Потому что любая специализированная программа в любом случае быстрее универсальной.

>но могут потянуть оптимизированные для конкретной платформы и конкретной архитектуры, не зажатые искуственными требованиями к проектированию приложения на Си

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

Если не считать атомной энергетики, с которой больше проблем, чем профита

не знаю какой Вы эколог, но маркетолог Вы точно плохой :) если бы так было как Вы говорите - никто бы не использовал

так что про атомную энергетику - это песни вида: «кот не может быть хорошим с точки зрения мышей»

> Интерестно бы Tomcat потестить. Думаю его обгонит только Apache, да и то на статических файлах.

Я тестировал. На статике до 1Кб томкат «из коробки» обгоняет Апач «из коробки» почти в два раза. Затем при увеличении размера отдаваемого файла Апач догоняет и обгоняет Томкат на несколько десятков процентов.

IIS обгоняет на статике всё.

Хм ... а с ngnix и т.п. легкими серверами сравнивали ? Это было бы интересно.

бывший одноклассник троешник, который закончил ПТУ, сейчас зашибает реальное бабло, построил себе уже домик в пригороде и купил машинку - не в кредит,

при зарплате рабочего класса 10000-12000 это где же он бабло реальное зашибает? уж не герычем ли барыжа на домик в пригороде с высоким забором скопил? знаем мы этих птушников, руки в крови по локоть, поэтому и стекла своих каенов тонируют

>Apache не готовы заплатить за лицензию на TCK, т.к. эта лицензия не переходит проектам-наследникам.
Проблема не в этом.
Хотя возможно и в этом тоже.
Но основная проблема в том, что Oracle ограничивает сферу применения.
К примеру запускать на мобильных полученную программу ты не имеешь права.

>Да, у явы есть некоторый overhead по памяти, временный, за счет того, что gc не уничтожает не нужные больше обьекты сразу.
Не только.
лет 10 назат писали сервер для разбора протока несколько мб/сек.
Java изза отсутствия данных хранимых в стэке просто сжирала все ресурсы сборщиком мусора.

написали на C++ так как не фанатики.

Я тогда кстати .net и заитересовался изза наличия у них типов на стэке.

читая Ваши посты превращаюсь в граммарнаци.

>Для идиотов, напоминаю. Средненький банковский сервер стоит примерно $300K..$400K. Если ты вдруг захочешь просадить его производительность в 5-6 раз, для того чтобы позволить кодерам на Java потешить их раздутое ЧСВ, а потом компенсировать производительность увеличением мощности в 5-6 раз.. Ну, вы поняли..
Не знаю в каких банках вы работали, но в RBC, TD, MBO(крупнейшие канадские банки), Bank of America лично наблюдал и Java и .Net при том что C++ практически вымер.

> Для идиотов, напоминаю. Средненький банковский сервер стоит примерно $300K..$400K. Если ты вдруг захочешь просадить его производительность в 5-6 раз, для того чтобы позволить кодерам на Java потешить их раздутое ЧСВ, а потом компенсировать производительность увеличением мощности в 5-6 раз.. Ну, вы поняли..

Дорогой, не надо ля-ля.

Цена простоя системы в банке обычно намного больше. И никто не будет нанимать очередного на всю голову плюсанутого, чтобы потом неделю банк не работал и разгребал последствия. Скорее разработка будет идти на Java. Может даже на Haskell. Но никак не на этом вашем поделии.

А насчет сомнительности.. Java тормозила всегда. Она тормозила вчера, тормозит сегодня, и будет тормозить завтра. И аргумент про супержелезо завтра мы уже слышали в течение всего времени существования Java. Поэтому на серьезных задачах Java и не используется.

Чушь. Часто она рвет плюсанутый код как тузик грелку. Причем работает стабильнее. Главное, чтобы программист был вменяемым.

BEA и ActiveMQ не имеем, т.к. они не подошли — не справились. гупо сравнивать самосвал и самокат, когда речь идёт о перевозке грузов.

кстати, томкат тот ещё тормоз. постоянно приходится прятать его за nginx с лютым кэшированием, иначе настаёт атас.

>Часто она рвет плюсанутый код как тузик грелку.

Если JVM написана на С/С++, то каким образом она может оказаться быстрее себя самой?

>>Часто она рвет плюсанутый код как тузик грелку.

Если JVM написана на С/С++, то каким образом она может оказаться быстрее себя самой?

Таким самым, как любая мало-мальски крупная программа на C/C++ оказывается быстрее чем такая же, написанная вручную в машинных кодах. Правда удивительно? Работает быстрее, хотя C/C++ компилятор компилячит через них. И хотя в теории, программа на машинных кодах может быть быстрее (т.к. C/C++ не использует все фичи процессора). Догадываешься почему так получается, или разжевать?

>Догадываешься почему так получается, или разжевать?

Разжуй, позязя.

>Цена простоя системы в банке обычно намного больше. И никто не будет нанимать очередного на всю голову плюсанутого, чтобы потом неделю банк не работал и разгребал последствия.
Существует такое понятие как контроль качества. Я что-то не замечал, чтобы от С++ программ было болше проблем чем от Java программ.

Чушь. Часто она рвет плюсанутый код как тузик грелку. Причем работает стабильнее.

:) ну и расскажите как сделать отклик прораммы в микросекудах с некольких трэйдерских серверов. Ядро Линукса оттюнено до предела.

>И хотя в теории, программа на машинных кодах может быть быстрее (т.к. C/C++ не использует все фичи процессора). Догадываешься почему так получается, или разжевать?
Мне разжуйте, пожалуйста. Очень интересно.

>>Цена простоя системы в банке обычно намного больше. И никто не будет нанимать очередного на всю голову плюсанутого, чтобы потом неделю банк не работал и разгребал последствия.

Существует такое понятие как контроль качества. Я что-то не замечал, чтобы от С++ программ было болше проблем чем от Java программ.

А вы их запускать пробовали?

Я ради смеха прогнал valgrind несколько популярных библиотек. Например xerces. С умилением наблюдал как valgrind нашел херову гору глюков. В основном в области работы с памятью.

Котроль качества, говорите? :-) Даже не смешно.

Чушь. Часто она рвет плюсанутый код как тузик грелку. Причем работает стабильнее.

:) ну и расскажите как сделать отклик прораммы в микросекудах с некольких трэйдерских серверов. Ядро Линукса оттюнено до предела.

Я писал программы на Java с откликом в микросекундах. Самый большой кусок времени выполнения - отправка данных на сетевой интерфес. Причем время отправки не отличалось от времени отправки такого же пакета на оттюненой программе на С. При этом программа еще и вела полноценные логи и не вылетала по сегфолтам, как принято у плюсовиков.

Ну а как именно я это делаю - знать Вам не обязательно. :-) Я не опен соурс пишу.

Кстати, аналогичный софт писал и на Haskell. Та же картина, но пишется еще легче и радостней.

И хотя в теории, программа на машинных кодах может быть быстрее (т.к. C/C++ не использует все фичи процессора). Догадываешься почему так получается, или разжевать?

Мне разжуйте, пожалуйста. Очень интересно.

Вообще-то еще в школе принято объяснять, как работает компилятор. Он, видите ли, анализирует код и старается выбрать оптимальную комбинацию инструкций для решения поставленной задачи. Для человека это почти непосильная работа. Максимум что человек может сделать, это потратить неделю и вылизать код в 30-40 инструкций.

То же самое и с Java. Она предоставляет инструментарий. Если не умеешь пользоваться - твои проблема. Если инструментария не хватает - используй native library. Native library можешь писать хоть на C, хоть на асме, хоть на черте с рогами.

очень познавательно. люблю беллетристику.

> Я писал программы на Java с откликом в микросекундах

Ну а как именно я это делаю - знать Вам не обязательно. :-) Я не опен соурс пишу.

«У нас есть такие приборы! Но мы вам о них не расскажем» (с)

>И хотя в теории, программа на машинных кодах может быть быстрее

Я люблю это выражение «в теории». Ассемблер для 86-х кончился, когда за короткий срок прошла волна различных, с точки зрения оптимизации, процессоров.

А в современных условиях о ассемблере даже заикаться как-то неприлично. Не можем мы себе больше позволить такую роскошь. Мы даже C себе позволить не всегда можем.

Потому что сейчас совсем другие требования. Взять ту же параллельность... Да она в общем случае достижима только на уровне виртуальной машины. Типичнейший пример — erlang. Распределенность, кстати, тоже.

А если хочется на ассемблере программировать... Бог мой! Сколько же случаев, когда ассемблер уместен... Взять тот же GA144. Под него пока нет компиляторов, и наверно, не будет в классическом смысле этого слова. Там все 144 ядра — твои.