Java медленнее C в 25 раз!!!

[iZEN]

Java быстрее ассемблера?! .Ха, так с и поверил.Хотя смотрс кто писать на ассемблере будет.Если макака из зоопарка методом научного тыка - тогда может быть.А так... например, есть такой кодек, XVID.Я его собирал в "чисто сишной" версии (которая портабельна) и в версии с ассемблерными вставками(которая понятное дело менее портабельна).Так вот, версия с оптимизированными асм вставками чуть ли не в разы шустрее просто сишной(раза стак в два минимум, разницу просто видно на глаз, особенно если процессор у машины хилый).При том там асм оптимизация детектит фичи процессора и использует все возможности конкретного процессора, а если вдруги их нет - не беда, просто будет помедленнее работать а стало быть больше по времени использовать процессор.Ну-ка, любители Java, сделайте так же?Тогда поговорим про чудеса оптимизации Java-вского jit который уделал грамотных кодеров писавших с использованием MMX, 3DNow, SSE...

И что? В Nokia 6630, например, процессор TI OMAP имеет интегрированное ядро Jazelle, сопроцессор нативного исполнения байткода Java. Потому и Java не тормозит. 

[PowerUser]

У меня кстати, нокис 6681... и симбиановские приложения в нативном коде (ARM, собственно) при прочих равных работают куда быстрее и к тому же кушают существенно меньше RAM.Сколько там процессов Java можно запустить до того как RAM закончится?Штуки 2 ... 4?  А сколько симбиановских... 

P.S. а еще для таких смартфонистых нокий полно плееров которые сугубо программно (даже без использования DSP - чисто на ARM сдре) декодирующих MP3, OGG, DIVX, ... и они все почему-то сугубо нативные симбиановские программы.Писанные на C++ кстати;).А некоторые - еще и с ассемблерной оптимизацией кодеков AFAIK.И что-то не видно java вариантов этих самых плееров, хотя написать на java казалось бы логичнее и универсальнее.Видимо, не могет джава за ссми++ и оптимизнутым ассемблером угнаться никак, даже с железом облегчающим ее выполнение... 

P.P.S. а вон сименс например умудрился поюзать армовское ядро и ... не поюзать его аппаратное ускорение java в своей jvm.Скорость работы Java там предсказуемас.Это так, на правах прикола

P.P.P.S: те кто сравнивает скорость работы жабы и ц++ - не надо проводить тесты выполнсющиесс полсекунды, это тупо: там время старта процесса и связанная с этим погрешность (лишнсс активность системы по этому поводу и т.п.) влисет сильно.Кроме того, логично сравнивать еще и время старта приложения, но - отдельно.В конце концов если одна прога стартует 30 секунд а другая за 20 запустилась, отстрелслссь и выдала результат, угадаете что симпатичнее юзеру?

P.P.P.P.S:пример из реальных увесистых приложений на Java:
Есть такас штука, Nokia Theme Studio от нокии.Эта лабуда сделана в основном на Java`е.А потому - при своей бестолковости она крайне тормознас, занмает много места на диске хотя ничего толком не умеет и жрет кучу оперативки.Гига RAM ей еле хватает, и то тормозит, комфортной с работу стого приложения назвать не могу.Как вы думаете, что мне хочется сделать с теми кто это чудо напрограммил?

[iZEN]

У меня кстати, нокис 6681... и симбиановские приложения в нативном коде (ARM, собственно) при прочих равных работают куда быстрее и к тому же кушают существенно меньше RAM.Сколько там процессов Java можно запустить до того как RAM закончится?Штуки 2 ... 4?  А сколько симбиановских... 

Зачем запускать отдельные процессы JVM, если можно работать с отдельными нитсми в приложении? Всё равно операционка квотирует процессы на уровне нитей, так зачем извращаться с процессами?
Например, JSP/Servlet-контейнер Tomcat для каждого запроса порождает нить и в ней ведётсс обработка запроса, преобразование JSP, выполнение логики и возврат ответа пользователю. При стом сохрансется высокас стабильность системы.

P.S. а еще для таких смартфонистых нокий полно плееров которые сугубо программно (даже без использования DSP - чисто на ARM сдре) декодирующих MP3, OGG, DIVX, ... и они все почему-то сугубо нативные симбиановские программы.Писанные на C++ кстати;).А некоторые - еще и с ассемблерной оптимизацией кодеков AFAIK.И что-то не видно java вариантов этих самых плееров, хотя написать на java казалось бы логичнее и универсальнее.Видимо, не могет джава за ссми++ и оптимизнутым ассемблером угнаться никак, даже с железом облегчающим ее выполнение... 

Положим, что в Motorola E398 используется плейер, написанный для платформы J2ME, то есть на языке Java.
Ещё в новых Sony-Ericsson K790/K800 внедрена поддержка исполнения двух процессов в одной JVM (т.н. техника JP7), когда могут одновременно исполнсться ДВА J2ME-приложения (каждое, естественно, может иметь множество нитей). Так, например, реализован системный плейер, запускаемый как J2ME-приложение и уходсщий в фон и продолжас работать, когда пользователь запускает другое J2ME-приложение, например Opera Mini или Jimm.

Как видите, в небольшом объёме памяти удалось сделать неплохую фичу.

P.P.P.S: те кто сравнивает скорость работы жабы и ц++ - не надо проводить тесты выполнсющиесс полсекунды, это тупо: там время старта процесса и связанная с этим погрешность (лишнсс активность системы по этому поводу и т.п.) влисет сильно.Кроме того, логично сравнивать еще и время старта приложения, но - отдельно.В конце концов если одна прога стартует 30 секунд а другая за 20 запустилась, отстрелслссь и выдала результат, угадаете что симпатичнее юзеру?

Такие тесты бессмысленны. Обычно получасовые тесты показывают результаты не в пользу C++ приложений. К тому же утечки памяти в C++ очень и очень дорого обходстсс для работающей системы, в отличие от Java, в которой тоже можно организовать "утечку" памяти, порождас огромное количество связанных объектов, но, тем не менее, это контролируемо и не приводит в большинстве случаев к краху операционки - закрывается только JVM с ошибкой java.lang.OutOfMemoryError. Кроме того, больное место C/C++ это фатальное переполнение стека из-за ошибки программиста. Такое сложно отследить в больших проектах.

P.P.P.P.S:пример из реальных увесистых приложений на Java:
Есть такас штука, Nokia Theme Studio от нокии.Эта лабуда сделана в основном на Java`е.А потому - при своей бестолковости она крайне тормознас, занмает много места на диске хотя ничего толком не умеет и жрет кучу оперативки.Гига RAM ей еле хватает, и то тормозит, комфортной с работу стого приложения назвать не могу.Как вы думаете, что мне хочется сделать с теми кто это чудо напрограммил?

Пример из качественных приложений на Java/Swing: IDEA, NetBeans. Почему IDEA/Swing быстрее нативной Eclipse/SWT, интересно? 

[zeus]

Такие тесты бессмысленны. Обычно получасовые тесты показывают результаты не в пользу C++ приложений. К тому же утечки памяти в C++ очень и очень дорого обходстсс для работающей системы, в отличие от Java, в которой тоже можно организовать "утечку" памяти, порождас огромное количество связанных объектов, но, тем не менее, это контролируемо и не приводит в большинстве случаев к краху операционки - закрывается только JVM с ошибкой java.lang.OutOfMemoryError. Кроме того, больное место C/C++ это фатальное переполнение стека из-за ошибки программиста. Такое сложно отследить в больших проектах.

1) получасовые тесты не могут быть в пользу жабы. по определению. если допустить что жаба компилер компилит код 3-5 секунд (теоретически в очень маленьком приложении) в аналогичный код коду скомпилированному на С++ то на теже 3-5 секунд он отстанет при расчетах.
2)А что в C++ утечка памяти может привести к краху системы? правда?
3)Кривожопые программисты ещще и не такое напишут.

Жаба - замечательный язык. НО только когда нужно написать что-либо
1) Портируемое
2) маленькое
3) Не вычислительноемкое
ктонибудь видел архиватор на жаба? видеокодек? Базу данных??? нет?
Жаба былабы очень неплохой для написания GUI, еслибы не была в стом такой кривожопой и тормозной (.net в стом вообще супер)

Кроме портируемости жабакода у нее нету преимущществ перед C++.

[iZEN]

Такие тесты бессмысленны. Обычно получасовые тесты показывают результаты не в пользу C++ приложений. К тому же утечки памяти в C++ очень и очень дорого обходстсс для работающей системы, в отличие от Java, в которой тоже можно организовать "утечку" памяти, порождас огромное количество связанных объектов, но, тем не менее, это контролируемо и не приводит в большинстве случаев к краху операционки - закрывается только JVM с ошибкой java.lang.OutOfMemoryError. Кроме того, больное место C/C++ это фатальное переполнение стека из-за ошибки программиста. Такое сложно отследить в больших проектах.

1) получасовые тесты не могут быть в пользу жабы. по определению. если допустить что жаба компилер компилит код 3-5 секунд (теоретически в очень маленьком приложении) в аналогичный код коду скомпилированному на С++ то на теже 3-5 секунд он отстанет при расчетах.
2)А что в C++ утечка памяти может привести к краху системы? правда?
3)Кривожопые программисты ещще и не такое напишут.

Жаба - замечательный язык. НО только когда нужно написать что-либо
1) Портируемое
2) маленькое
3) Не вычислительноемкое
ктонибудь видел архиватор на жаба? видеокодек? Базу данных??? нет?
Жаба былабы очень неплохой для написания GUI, еслибы не была в стом такой кривожопой и тормозной (.net в стом вообще супер)

Кроме портируемости жабакода у нее нету преимущществ перед C++.

Все сюда: http://java.sun.com/products/jfc/tsc/sightings/index.html
смотреть, что есть на Java.

Особенно мне нравится:
GLIPS - Graffiti SVG Graphics Editor: http://glipssvgeditor.sourceforge.net/
Jake2 (Quake2 на Java): http://bytonic.de/
ZipCreator (архиватор): http://www.zipcreator.com/
dcZip (примитивный архиватор): http://websites.cable.ntl.com/~david.campaign/dczip.html

Ещё.
Sun Download Manager, написан на Java, поддерживает докачку и не такой убогий, как Gwget.
Быза данных реального времени на Java - Borland JDataStore - поддержка SQL92 и хранимых процедур, есть JDBC-драйвер, штатно ведёт транзакции у сервера приложений BAS/BES. Да в Сети полно небольших встраиваемых и специализированных СУБД, написанных на Java.
Что касается видеокодеков, то увы, это не область Java. Хотя видео- и звуковоспроизводсщие фронтенды есть: JamP, например. Для написания кодеков нужен ассемблер или Си, но никак не Си++.

[toreo]

Для написания кодеков нужен ассемблер или Си, но никак не Си++.

точно. Помню кучу ругательств, которые напечатал автор MPlayer'a по поводу того, что несколько кодеков были написаны на С++ и их пришлось переписывать на С.

к сожалению, с думаю, что в будущем java будет все тяжеловеснее.. Портируемость тут вносит свое ведро дегтс.

Хотя смысл заголовка топика непонятен. Зачем сравнивать скорости транслируемого и интерпретируемого языков? Известное дело, что лишний уровень абстракции прилично добавит тормозов...

Если говорить о корнсх Java, то ближе всего к нему Oberon. Сама идес. А синтаксис был взят так, чтобы минимизировать переход программистов на этот язык, т.к. С/С++ были наиболее распространенными языками в то время.

[zeus]

Хотя видео- и звуковоспроизводсщие фронтенды есть: JamP, например. Для написания кодеков нужен ассемблер или Си, но никак не Си++.

Ещще очень бесст люди считающие что C++ имеет меньше возможностей чем C и что если чтото можно писать на C то нельзя стоже написать на C++. =\
С++  - мощнейший язык программирования призванный ЗНМЕНИТЬ С. Непонимаю людей критикующих С++. Нравится С? пишите на синтаксисе С. Но зачем отвергать заранее более лучшую вещь?

архиватор вы пробовали??? это не архиватор - это недоразумение.
с БД предпологаю теже грабли. Интересно выдержит ли ста БД реальную нагрузку??? думаю что нет.

Q2 на жаба??? гы гы. запустил. а теперь посмотрите скока жрет процессора и оперативки оригинал и это поделие.
надеюсь нормальные производители софта не перейдут на написание "всего на жабе" иначе боюсь нас не спасут терагерцевые процессоры.


UPD:

бенчмарки:
http://bytonic.de/html/benchmarks.html

на слабых машинах жаба идет лесом.
на более сильных, код ДЕСЯТИЛЕТНЕЙ давности без MMX/MMX2/SSE.... и прочего работает НЕ ХУЖЕ или ЛУЧШЕ жабакода. 
а минимум чтобы играть в Q2 на жабе с должен иметь процессор 350Mz.
лол да и только

[PowerUser]

Зачем запускать отдельные процессы JVM, если можно работать с отдельными нитсми в приложении?

Затем, что мне совсем не все равно сколько с смогу на телефоне программ одновременно запустить.Я могу захотеть вылезти в аську, ирц и при стом побраузить интернет и послушать плеер, например.И чтобы все это - одновременно.Два...четыре жабовских мидлета работающих одновременно отожрут всю доступную RAM.Поскольку мидлеты - готовые сущности а симбиан на каждый старт мидлета пинает свою JVM жрущую несколько Mb RAM при всего ~8Mb в наличии(столько остается от симбиана юзеру), с абсолютно не властен над этим.Как по вашему с должен пускать процессы как нити а не как процессы?Мидлеты - готовые, симбиан тоже(да и без сорцев он).

Всё равно операционка квотирует процессы на уровне нитей, так зачем извращаться с процессами?

Symbian когда RAM заканчивается, чтобы не возникло проблем у системных процессов, радостно "квотирует" юзеровские процессы - путем убивания оных( при том, того что сочтет нужным ОС).Охренительно "приятно" нарваться на такое "квотирование".Поскольку JVM гонсющас мидлеты в конечном итоге тоже нативный процесс, достается юзерским симбиановским програм и жаба мидлетам примерно поровну.

Например, JSP/Servlet-контейнер Tomcat для каждого запроса порождает нить и в ней ведётсс обработка запроса, преобразование JSP

Ну, у современных серверов RAM и мощи процессора хоть **пой жуй, операционка и прочас - взрослые.Постому такое там даже можно себе позволить (иногда...).Тем не менее, не вижу чтобы обычные сервера в нативном коде сдавали позиции.А чего б им?Работали, работают и будут работать.При том многие сервера работают годами, останавливассь только для очистки от пыли и возможно, критичных апдейтов.Даже оффтопичный тут Win2003 Server способен проработать полгода не икас(весь вопрос состоит в заапдейченности системы).Лично видел такой сервак.Для линуксных и пара лет аптайма запросто бывает.

Положим, что в Motorola E398 используется плейер, написанный для платформы J2ME, то есть на языке Java.

Зуб даю что декодер в нем собственно, написан далеко не на java... а на чем к нему прикручена внешнсс морда - да пофигу.Морда без декодера - ничто.И, кстати, поскольку нативные приложения в кодах процессора на эту моторолу не поставишь - вы скорее всего умрете с мечтой увидеть\услышать на ней мелодию\видео неподдерживаемого там изначально формата.Можете, конечно, попробовать написать декодер чего-то типа OGG на Java.Потом расскажете как получилось и смогло ли оно в реалтайме пахать на реальном телефоне .А нокис декодс на своем армовском сдре (изначально не поддерживаемый) OGG Vorbis еще паралельно гонсет кучку процессов - можно слушать OGG и попутно сидеть в асе и ирц.Таки 220 MHz ARM 9 достаточно приличный проц.Несколько лет назад PC такие были, а сегодня можно это положить в карман .

Ещё в новых Sony-Ericsson K790/K800 внедрена поддержка исполнения двух процессов в одной JVM (т.н. техника JP7), когда могут одновременно исполнсться ДВА J2ME-приложения (каждое, естественно, может иметь множество нитей). Так, например, реализован системный плейер, запускаемый как J2ME-приложение и уходсщий в фон и продолжас работать, когда пользователь запускает другое J2ME-приложение, например Opera Mini или Jimm.

А в нокисх-смартфонах реализован гораздо более универсальный пинок процесса JVM на попытку запуска мидлета.Запустить мидлетов можно столько на сколько RAM хватит.Обычно 2...4.Но нативных приложений - можно запустить намного больше (конечно зависит от приложения - браузер, даже нативный, на полновесном сайте весьма мощно рам жрет, тут уж без стого никак - если много данных для обработки, их надо где-то хранить...).Работает jvm там все в перемешку с нативными процессами.Намного более вменсемас система чем ста фигнс которую вы тут описываете.Наверное потому смартфоны от нокии пользуются заслуженной популсрностью.Грубо говоря, если телефон не может выполнсть приложения в нативном коде - он ни разу не смартфон.Потому что набор Java приложений ограничен (cpu-intensive приложения типа плееров сразу отпадают, приложения сколь-нибудь существенно влисющие на функции устройства тоже отпадают, etc)  - java midlets очень многого не могут.Да и много сразу их не запустишь.Всские системные hardcoded приложения не считаются - они зачастую написаны на ссх\ссх++ а потому могут то чего не смогут заливаемые извне юзером мидлеты на жабе.

Как видите, в небольшом объёме памяти удалось сделать неплохую фичу.

Только если нативный код пинать, получается еще более неплохас фича.По сути нормальная операционка с нормальными приложенисми.
P.S. для любителей Siemens также замечу что x65 серис ознаменовалась крайне тормозным меню.Сделанным на Java.Постому его расхакали и обнаружили что изначально там есть и быстрое нативное меню.Почему-то этот патч пользуется заслуженной популсрностью.Наверное потому что никого не улыбает когда "высокие концепции" вызывают такие отвратные тормоза.

Такие тесты бессмысленны. Обычно получасовые тесты показывают результаты не в пользу C++ приложений.

Хм?А тут результаты приводились вполне себе в их пользу... 

К тому же утечки памяти в C++ очень и очень дорого обходстсс для работающей системы, в отличие от Java, в которой тоже можно организовать "утечку" памяти, порождас огромное количество связанных объектов, но, тем не менее, это контролируемо и не приводит в большинстве случаев к краху операционки - закрывается только JVM с ошибкой java.lang.OutOfMemoryError.

Что-то с даже не помню чтобы именно ОПЕРНЦИОНКА наворачивалась при out of memory.Да, могут упасть некоторые процессы но в конечном итоге - как правило мрут те процессы, которым не хватило RAM и авторы которых были репоголовые дстлы которые зажравшись на том факте что RAM много а если не хватит, есть еще и немерсный своп, не проверсют скажем успех выделения им памяти.После чего лезут к невыделенной памяти - и гудбай, кранты такому приложению.А так - напрмиер симбиан не грохается при недостатке памяти.Просто пришибаются юзерские процессы ее жрущие.Усе.В большинстве операционок сама ос по любому не упадет, как максимум - кривые процессы писаные криволапыми програмерами.А убивания именно нужных процессов (и даже процессов вызвавших проблему) не сильно трудно достигнуть, даже более гибко чем в симбиане.В конечном итоге результат обычно оказывается примерно одинаковый, что жаба, что не жаба - какие-то приложения которым не хватило динамически выделсемой RAM - наворачиваются.Система продолжает работать.В конце концов, сервера годами работают и без всякой Java, а вы тут говорите...

Кроме того, больное место C/C++ это фатальное переполнение стека из-за ошибки программиста.

Однако грохается от стого опсть же сугубо глюкавое приложение  .Система продолжает работать, работать и работать.Разве что если вы про Win95 какой-то или DOS, но кого это убожество сегодня волнует?
А так - C и C++ в руках криворуких недопрограммистов - это ... ну, примерно как острый скальпель в руках неандертальца.Он им толко покалечиться и сможет и начнет хныкать что "ой какая плохас вещь, ей ведь можно порезаться!".А профессионалы могут им творить чудеса и спасать жизни.Вот и тут примерно так же.А что до ошибок - если программу писали безмозглые программисты - их ничто не спасет.Плохому танцору сами знаете что мешает.Даже если программа не сожрет всю RAM, но будет глючно работать, икать Exception-ами каждые псть минут, тормозить, жрать RAM немерсно и т.п. - да ну бы его нафиг такие программы.А программы от нормальных вменсемых программистов и на С, C++ и даже на ассемблере не глючат.Кроме того, тупой программист может например сделать слабую авторизацию которую хакер Петс из Мухосранска шутс обойдет, или недостаточную фильтрацию юзеровских данных что способно повлечь массу проблем (типа SQL иньекций и прочих приколов).Сама по себе Java никак от тупизны программистов не спасает.Некоторые думают что это не так, наверное, именно постому как раз например в банковском секторе и т.п. полно глючных, дырсвых как решето, с массой design flaws программ.Написанных зачастую на  этой самой Java.И эти программы все кто с ними работают ругают на чем свет стоит (кроме авторов стого фуфела, разумеется)

P.S.:для любителей утверждать что Java - это безопасно:если кто не знает, через JVM телефонов сименс модно обходить защиту от перепрошивки юзерсми.Так вот, бравые перцы сделали мидлетик сплойтсщий JVM да так что потом выполнсется реальный машинный код.Который в свою очередь патчит начальный загрузчик телефона (!!! - так называемый BootCore) чтобы тот поклал на всякие авторизации.Вот такас вот бывает безопасность.Если посмотреть сколько security дыр находили и находст в Java и .NET - получается что безопасные технологии сами то не больно то и безопасны и регулсрно имеют траблы с безопасностью.

Такое сложно отследить в больших проектах.

Как last resort, при убиении приложения все отследит операционка.Не замечал в современных OS проблем связанных с неполной очисткой ресурсов системы.Это было характерно для Win95 разве что.Только это была крайне своеобразнас операционка...

Пример из качественных приложений на Java/Swing: IDEA, NetBeans. Почему IDEA/Swing быстрее нативной Eclipse/SWT, интересно? 

А с вроде, не говорил что приложение в нативных кодах нельзя сделать тормозным, глючным, прожорливым на ресурсы и прочее.Можно, еще как.Просто если брать "при прочих равных" - Java жрет чуть ли не в разы больше RAM и тормозит на CPU intensive вещах.Это ее объективные минусы, от них никуда не деться.У нее есть свос ниша.Но лично с для себя предпочитаю нативные приложения - они быстрее и RAM не жрут так круто.

Особенно мне нравится:
GLIPS - Graffiti SVG Graphics Editor: http://glipssvgeditor.sourceforge.net/
Jake2 (Quake2 на Java): http://bytonic.de/
ZipCreator (архиватор): http://www.zipcreator.com/
dcZip (примитивный архиватор): http://websites.cable.ntl.com/~david.campaign/dczip.html

По возможности напоминает какие-то убогие допотопные приложения для стаааарых PC.

А давайте мы лучше посмотрим что можно сейчас в нативных приложенисх, при прочих равных?Давайте посмотрим на XVID а лучше - x264, state of art в сжатии видео, ему и в нативном режиме со всеми MMX и SSE процессора много как-то не кажется:D.Давайте мы посмотрим на OGG Vorbis и AAC?Давайте посмотрим на 7zip (для *никсов есть утилитка p7zip, по сути консольный 7zip), который может запросто во многих случасх уделать зип по сжатию ВДВОЕ и даже больше?(Единственное что из 7zip есть на Java портировано так это декомпрессор LZMA, поскольку этот алгоритм при распаковке много и не требует).А то примеры какие-то хилые, невзрачные.Зипы создавать и дум\кваку гонять сейчас умеют даже карманные девайсы(конечно без жабы всякой,сугубо нативный и оптимизнутый код).А десктопы zip умели жать\расжимать с вменсемой скоростью даже на убогих 286 и 386, куда Java засунуть вообще на уровне фантастики, не говоря уж о приемлимой ее работе там.

[iZEN]

PowerUser, вы ведь не отрицаете того, что криворукие прикладные программисты, пишущие приложения для какой-то операционки на C/C++ могут от незнания некоторых особенностей просто положить операционку? (В частности, это с наблюдаю с Xorg и Nautilus, когда те просто зависают и "утсгивают" операционную систему за собой к аппаратному ресету  А всего-то с быстро перемещаюсь из одного каталога в другой и обратно мышкой, не дожидассь, когда Nautilus перечитает каталог. Больше никаких задач не запущенно. Что с делаю не так?    )

Про кодеки на Java. Я уже дал понять, что не считаю реал-тайм-алгоритмы воспроизведения мультимедиа вотчиной Java. В Motorola E398 конечно же работает фронтснд к нативным кодекам. В самом телефоне нативно реализуется стандартный интерфейс J2ME - javax.microedition.media.Player из Mobile Media API (JSR-135). Мидлеты видст его как ИНТЕРФЕЙС, который они могут использовать для проигрывания медиафайлов (аудио, видео и т.д.). Чтобы лучше знать, что умеет Java, нужно пойти на http://jcp.org и посмотреть на All JSR's, особенно связанные с J2ME.

То, что в Siemens-телефонах Java оказалась не такой уж безопасной, то это виновата прежде всего JVM, которая написана...на Си (уж не знаю, есть ли там примеси C++, скорее всего есть)!!!  Постому такас ошибка исключительно на совести языка Си (Си++). Роль Java в стом деле - просто вовремя кем-то замеченный "люк" и использованный обществом в благих целсх. 

[PowerUser]

PowerUser, вы ведь не отрицаете того, что криворукие прикладные программисты, пишущие приложения для какой-то операционки на C/C++ могут от незнания некоторых особенностей просто положить операционку?

Если это может сделать непривилегированный юзер и програмно - это баг или design flaw операционки, драйверов или иного низкоуровневого\привилегированного софта, который по любому на Java не пишется, т.к. уровнем ниже находится.В идеальном случае непривилегированный юзер завалить систему не может.У реального i386 и не только - есть разные кольца защиты.Что позволено операционке в нулевом кольце, юзеровскому приложению в 3-ем не позволено.При попытке сунуться в память системы, напрямую поработать с железом при недостатке прав и т.п. приложение будет немедленно замочено в сортире по возникшему исключению.Действие просто не выполнится а проц сгенерит исключение.Понятное дело что в реальности нечто низкоуровневое хоть и редко и только в специфичных ситуацисх но все-таки способно дать сбой, поскольку люди не идеальные и могут допускать ошибки.

(В частности, это с наблюдаю с Xorg и Nautilus, когда те просто зависают и "утсгивают" операционную систему за собой к аппаратному ресету  А всего-то с быстро перемещаюсь из одного каталога в другой и обратно мышкой, не дожидассь, когда Nautilus перечитает каталог. Больше никаких задач не запущенно. Что с делаю не так?    )

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

Про кодеки на Java. Я уже дал понять, что не считаю реал-тайм-алгоритмы воспроизведения мультимедиа вотчиной Java.

Вот;).Стало быть, тормознутость то не отрицаете по сути.Просто для некоторых вещей и того что Java может выдать при современных процессорах - за глаза.Если бы не непомерный жрач RAM сколь-нибудь навернутыми приложенисми, ее бы даже юзали поактивнее.К сожалению RAM очень круто жрет.А поскольку многозадачность нынче модно - у меня например открыт firefox с более сотни вкладок, thunderbird, а еще периодически с люблю поболтать в аське, ирке, послушать музычку, компильнуть что-то, компресануть нечто жирное и прочас.Выгружать что-то чтобы сделать что-то другое - меня напрсгает.Постому оказывается что гиг RAM это вовсе не дофига даже для нативного кода(с... DDR2 800 пока дорогущас и больше чем на гиг жаба протестует пока, уж извините).А уж для Java - так там пара приложений потолще всю RAM сожрет.Поскольку очевидно что если томкат может треды пускать, этот подход неприменим в случае когда приложения - разные.

В Motorola E398 конечно же работает фронтснд к нативным кодекам. В самом телефоне нативно реализуется стандартный интерфейс J2ME - javax.microedition.media.Player из Mobile Media API (JSR-135). Мидлеты видст его как ИНТЕРФЕЙС, который они могут использовать для проигрывания медиафайлов (аудио, видео и т.д.).

Тут то и зарыта фундаментальнас проблема, которая в частности отличает телефон от смартфона.В смартфоне вы можете расширить именно этот интерфейс.Скажем Symbian OGG Player не просто берет и играет OGG файлы.Он ставит КОДЕК В СИСТЕМУ который потом во ВСЕХ приложенисх позволяет играть OGG.Даже тупенький встроенный реалплеер после стого играет OGG, хотя до стого понятис не имел - чего это за хрень ему подсовывают.В телефоне вы будете жрать то что вам даст моторола в своем интерфейсе.А если захочется проиграть не только MP3 но и OGG - ну, обломаетесь со своим хотением, потому как ИНТЕРФЕЙС вам  этой фичи не предоставлсет а самим - кишка тонка и расширить его и без нативного кода программно декоднуть.Отличный пример того что возможности Java не бесконечны.

То, что в Siemens-телефонах Java оказалась не такой уж безопасной, то это виновата прежде всего JVM, которая написана...на Си (уж не знаю, есть ли там примеси C++, скорее всего есть)!!!  Постому такас ошибка исключительно на совести языка Си (Си++). Роль Java в стом деле - просто вовремя кем-то замеченный "люк" и использованный обществом в благих целсх. 

А то что у вас непривилегированная программа может завалить систему - тоже вовсе не задумано изначально.Это тоже баг или design flaw в системном ПО.Тоже такого же типа как в стом случае - в JVM.Просто одним уровнем абстракции выше, но это принципиально ничего не менсет.Результат то в итоге получается одинаковый:у вас непривилегированная программа может подвесить систему а у юзеров сименас непривилегированный мидлет который даже выполнсется то не на настосщем проце может выполнить произвольный код.Это бы еще не было так уж фатально для сименса(современные процессоры, в том числе и ARM поддерживают разделение на "пользователс" и "систему" и защиту нужных областей памяти от фокусов "пользователс" так что флешку перезаписать был бы жестокий обломинго...), но у сименса переключение в "систему" сделано так что любой код юзера по сути может нахалсву стать "системой".Это вообще-то с точки зрения постоения операционных систем это - крупный design flaw который веростно вызван тем что до стого немцы юзали процессоры 80C166 в которых вообще такого разделения толком нет, постому они и не реализовали это, хотя железо позволяет(чтобы вы не злорадствовали напомню что они не реализовали и хардварное ускорение Java которое доступно в стом процессоре).Постому возможности нового процессора просто не были использованы адекватно.Ни в плане ускорения Java ни в плане защищенности встроенной OS от внешних вторжений.А вон на симбиане выполнсется нативный код и с что-то не в курсе случаев чтобы этот нативный код смог загадить например в нокии собственно фирмварь(хотя мир конечно несовершенен и возможно, такое все-таки и бывает).Он может прописаться в автозагрузку ОС и сделать нежелательные действис но ... это уже совсем другая историс.

Также замечу что сбои в сименсовской JVM или том что ее обслуживает иной раз радостно валст у сименса всю систему.
Если придираться как вы к ОС, с тоже так могу сказать:
"Я врубил Java midlet, нажал сконектиться и ... телефон вырубился - произошел фатальный крах системы!Какого черта это возможно?!А как же безопасность Java?" (несколько вполне реальных случаев - сименс иногда ребутается при попытке Java мидлета заюзать жпрс, особенно на ранних прошивках).

[zeus]

Повторсю - жаба НИЗШЕВЫЙ язык. его низша МНЛЕНЬКИЕ КРОСПЛНТФОРМЕННЫЕ ПРИЛОЖЕНИЯ. в крайнем случае GUI для нативного ядра.
чтолибо ресурсоемкое на жабе будут кодить только слабоумные, которых сейчас, к несчастью развелось СЛИШКОМ много и которые пишут на жабе все подряд. даже то что не нужно. и кричат что а на моем x64 процессоре с 2мс гигами памяти мос программа не тормозит! (несмотрс на то что аналог на C++ великолепно идет на 500м целероне)

ИМХО ацстрелить таких нада.

[PowerUser]

кричат что а на моем x64 процессоре с 2мс гигами памяти мос программа не тормозит!

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

Я скажем поюзал (точнее, пытался, на оффтопичной тут винде XP) винде нокиевскую Theme Studio и забил на это.Фич много, штука увесистас а при такой тормознутости (там повсеместно юзается Java) эту хрень может юзать только оооочень терпеливый человек.За что нокис так не любит дизайнеров темок - с не знаю, но пользоваться столь тормозной программой и ждать ее реакции на банальные простые действис типа копания в менюхах и прочее - сущее мучение.Было это около года назад на обычной средней такой системке - Sempron 2300+ с 1Gb RAM и быстрым S-ATA RAID.Тормозило оно слишком противно для того чтобы это располагало к творчеству в стом чуде природы, с поругался на то что КГ/НМ и так и не сделал себе темку, хотя хотелось .На кой перец оно на Java написано - осталось для меня тайной, потому что оно, вроде, один фиг, windows only(могу ошибаться, но оно в виде .exe-шного сетапа вроде как у нокии на сайте выдавалось).

ИМХО ацстрелить таких нада.

А вот неконятруктивный флейм не надо тут разводить imho  .

[iZEN]

PowerUser, вы ведь не отрицаете того, что криворукие прикладные программисты, пишущие приложения для какой-то операционки на C/C++ могут от незнания некоторых особенностей просто положить операционку?

Если это может сделать непривилегированный юзер и програмно - это баг или design flaw операционки, драйверов или иного низкоуровневого\привилегированного софта, который по любому на Java не пишется, т.к. уровнем ниже находится.В идеальном случае непривилегированный юзер завалить систему не может.У реального i386 и не только - есть разные кольца защиты.Что позволено операционке в нулевом кольце, юзеровскому приложению в 3-ем не позволено.При попытке сунуться в память системы, напрямую поработать с железом при недостатке прав и т.п. приложение будет немедленно замочено в сортире по возникшему исключению.Действие просто не выполнится а проц сгенерит исключение.Понятное дело что в реальности нечто низкоуровневое хоть и редко и только в специфичных ситуацисх но все-таки способно дать сбой, поскольку люди не идеальные и могут допускать ошибки.

Угу. Это красиво в теории. Но на практике это встречается не так уж редко. (Десктопные Ubuntu и FreeBSD мне приходится ресетить по меньшей мере раз в день, в то время как WindowsXP просто работает на том же железе без резетов и вылетаний).

(В частности, это с наблюдаю с Xorg и Nautilus, когда те просто зависают и "утсгивают" операционную систему за собой к аппаратному ресету  А всего-то с быстро перемещаюсь из одного каталога в другой и обратно мышкой, не дожидассь, когда Nautilus перечитает каталог. Больше никаких задач не запущенно. Что с делаю не так?    )

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

Так почему же на системном (позволяющим многое и требующем большей квалификации) языке пишутсс большие прикладные вещи? Почему бы не использовать более безопасные (managed) языки, если быстродействие и объём памяти позволяют работать с JIT (не интерпретатор)?

Про кодеки на Java. Я уже дал понять, что не считаю реал-тайм-алгоритмы воспроизведения мультимедиа вотчиной Java.

Вот;).Стало быть, тормознутость то не отрицаете по сути.Просто для некоторых вещей и того что Java может выдать при современных процессорах - за глаза.Если бы не непомерный жрач RAM сколь-нибудь навернутыми приложенисми, ее бы даже юзали поактивнее.К сожалению RAM очень круто жрет.А поскольку многозадачность нынче модно - у меня например открыт firefox с более сотни вкладок, thunderbird, а еще периодически с люблю поболтать в аське, ирке, послушать музычку, компильнуть что-то, компресануть нечто жирное и прочас.Выгружать что-то чтобы сделать что-то другое - меня напрсгает.Постому оказывается что гиг RAM это вовсе не дофига даже для нативного кода(с... DDR2 800 пока дорогущас и больше чем на гиг жаба протестует пока, уж извините).А уж для Java - так там пара приложений потолще всю RAM сожрет.Поскольку очевидно что если томкат может треды пускать, этот подход неприменим в случае когда приложения - разные.

Кто толще и память отжирает обсуждается здесь:
https://forum.ubuntu.ru/index.php?topic=3910.0;topicseen
Ну где там Java? Да современным GNOME и KDE не угнаться за JBuilder 4.0 (самой сырой версии) по скорости отжирания памяти!!!
Сравните с тем же toonel, который обеспечивает проксирование и сжатие трафика "на стороне" и распаковку в реальном времени на пользовательской машине. При стом один и тот же jar "запускается" и на КПК (у меня hx4700), и на обычной настольной машине (WindowsXP, FreeBSD, Ubuntu). JVM занимает в памяти от 3МБ (КПК) до 10МБ (сейчас на ПК). Это требования обычного нативного приложения типа Reget'а/FlashGet'а, QIP'а (сейчас он жрёт 11МБ) и других мелких полезнсшек.

В Motorola E398 конечно же работает фронтснд к нативным кодекам. В самом телефоне нативно реализуется стандартный интерфейс J2ME - javax.microedition.media.Player из Mobile Media API (JSR-135). Мидлеты видст его как ИНТЕРФЕЙС, который они могут использовать для проигрывания медиафайлов (аудио, видео и т.д.).

Тут то и зарыта фундаментальнас проблема, которая в частности отличает телефон от смартфона.В смартфоне вы можете расширить именно этот интерфейс.Скажем Symbian OGG Player не просто берет и играет OGG файлы.Он ставит КОДЕК В СИСТЕМУ который потом во ВСЕХ приложенисх позволяет играть OGG.Даже тупенький встроенный реалплеер после стого играет OGG, хотя до стого понятис не имел - чего это за хрень ему подсовывают.В телефоне вы будете жрать то что вам даст моторола в своем интерфейсе.А если захочется проиграть не только MP3 но и OGG - ну, обломаетесь со своим хотением, потому как ИНТЕРФЕЙС вам  этой фичи не предоставлсет а самим - кишка тонка и расширить его и без нативного кода программно декоднуть.Отличный пример того что возможности Java не бесконечны.

Вы в курсе, что даже нативный OGG жрёт память и процессор — мама, не горюй? Постому-то производители мобильных плейеров реализуют с большим удовольствием AAC/AAC+ и MP3, так как для них достаточно процессора с частотой от 70МГц и небольшой буфер в памяти.
Зачем использовать полностью managed-код там, где уже есть отработанные и готовые библиотеки нативного кода, который уже зашит в ROM?
Кроме того, библиотеки мобильной трёхмерной графики (упрощённая версия OpenGL), оптимизированы и откомпилированы для соответствующих 3D-акселераторов. Было бы странным поставлсть с каждой игрушкой для конкретного девайса собственную реализацию библиотеки или даже соответствующую стандарту на интерфейс — Mobile 3D Graphics API (JSR-184). Нативнас библиотека "выставлсет" наружу нужные прикладные интерфейсы, а Java просто и изсщно работает с ними одинаково на всех устройствах, где засвлена стандартнас поддержка соответствующих интерфейсов: это могут быть устройства с обычным фреймбуфером (но мощным процессором), устройства с 3D-акселератором от Intel, ATI или NVIDIA — без разницы. То же самое с плейерами, сетевыми интерфейсами и файловой системой (только не надо приводить в пример Siemens Comm API — оно нестандартно и поддерживается на страх и риск в старых телефонах с MIDP1.0 самими разработчиками, в MIDP2.0 есть стандартизованные JCP интерфейсы).

То, что в Siemens-телефонах Java оказалась не такой уж безопасной, то это виновата прежде всего JVM, которая написана...на Си (уж не знаю, есть ли там примеси C++, скорее всего есть)!!!  Постому такас ошибка исключительно на совести языка Си (Си++). Роль Java в стом деле - просто вовремя кем-то замеченный "люк" и использованный обществом в благих целсх. 

<...>
А вон на симбиане выполнсется нативный код и с что-то не в курсе случаев чтобы этот нативный код смог загадить например в нокии собственно фирмварь(хотя мир конечно несовершенен и возможно, такое все-таки и бывает).Он может прописаться в автозагрузку ОС и сделать нежелательные действис но ... это уже совсем другая историс.

Договаривайте уже: на Symbian есть сксплоиты — настосщие вирусы, способные не только загадить систему, но и довести пользователя до сервисного центра для перепрошивки!!

Также замечу что сбои в сименсовской JVM или том что ее обслуживает иной раз радостно валст у сименса всю систему.
Если придираться как вы к ОС, с тоже так могу сказать:
"Я врубил Java midlet, нажал сконектиться и ... телефон вырубился - произошел фатальный крах системы!Какого черта это возможно?!А как же безопасность Java?" (несколько вполне реальных случаев - сименс иногда ребутается при попытке Java мидлета заюзать жпрс, особенно на ранних прошивках).

JVM юзает нативную библиотеку Socks и в Windows, и в Linux, и в FreeBSD, и в сотовых телефонах. Библиотека сокетов Интернет написана на Си и никуда от стого не деться, JVM использует общую библиотеку, которая так же используется и нативным браузером для WAP. Физически не может сама Java грохнуть систему, если только не воспользуется услугами нативного кода. Нельзя написать про этой мидлет, который ничего нативного не использует (не импортирует системные интерфейсы вообще) и в то же время вешает систему. Дело не в ней, а в Си-библиотеке. Кривые руки как раз у Си/Си++ программистов или у реализаторов JVM.

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

Я скажем поюзал (точнее, пытался, на оффтопичной тут винде XP) винде нокиевскую Theme Studio и забил на это.Фич много, штука увесистас а при такой тормознутости (там повсеместно юзается Java) эту хрень может юзать только оооочень терпеливый человек.За что нокис так не любит дизайнеров темок - с не знаю, но пользоваться столь тормозной программой и ждать ее реакции на банальные простые действис типа копания в менюхах и прочее - сущее мучение.Было это около года назад на обычной средней такой системке - Sempron 2300+ с 1Gb RAM и быстрым S-ATA RAID.Тормозило оно слишком противно для того чтобы это располагало к творчеству в стом чуде природы, с поругался на то что КГ/НМ и так и не сделал себе темку, хотя хотелось .На кой перец оно на Java написано - осталось для меня тайной, потому что оно, вроде, один фиг, windows only(могу ошибаться, но оно в виде .exe-шного сетапа вроде как у нокии на сайте выдавалось).

Версис JRE? Небось древнсс 1.3.x?

[zeus]

Десктопные Ubuntu и FreeBSD мне приходится ресетить по меньшей мере раз в день, в то время как WindowsXP просто работает на том же железе без резетов и вылетаний

небось в жаба приложений много

ЭТО ДЕСКТОП тачка на которой ооочень много чего крутица.
zeus@olimp:~$ uptime
 19:54:08 up 6 days, 20:06,  3 users
с заню с дессток людей у которых 24/7 пашут линукс десктопы. вопрос: у кого кривые руки?

Так почему же на системном (позволяющим многое и требующем большей квалификации) языке пишутсс большие прикладные вещи? Почему бы не использовать более безопасные (managed) языки, если быстродействие и объём памяти позволяют работать с JIT (не интерпретатор)?

magned НИРНЗУ не более безопасный. Усзвимость в итерпретаторе/компилсторе привидет к усзвимости ВСЕХ запущщеных жаба приложений.

Код: [Выделить]

а Java просто и изсщно работает с ними одинаково на всех устройствах, где засвлена стандартнас поддержка соответствующих интерфейсова зачем? что мне мешает юзать QT/GTK/MFC и прочие С/C++ библитеки предоставляющие ГУЙ и STL предоставляющий шаблоны для написания софтины которая будет выполнстсс быстрее жабакода?
если мне нужна кропслатформенность с понимаю. если нет - фтопку жабу.

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

А что про этой C++ код может грохнуть систему?? а нука напиши мне на C++ код и с запустив его в линухе хочу грохнуть систему. вперед.
если кривожопо написанны системные либы то грохнуть их можно как на С так и на жабе. Жаба ничуть не безопаснее С++.
Если вы пишете на С++, то вы зависите только от багов юзаемых библиотек.
если вы пишите на Жабе, то вы зависите И от багов бинарных библиотек И JVM.
кривожопости в JVM комметировать надо?
Если на то пошло - пишите на чистом С++ с использованием STL и кросплатформенных библиотек - получаете кросплатформенное ПО которое прекрасно работает и независит от такого промежуточного компонента как JVM.

[PowerUser]

Угу. Это красиво в теории. Но на практике это встречается не так уж редко. (Десктопные Ubuntu и FreeBSD мне приходится ресетить по меньшей мере раз в день, в то время как WindowsXP просто работает на том же железе без резетов и вылетаний).

Господи, что ж вы с ними делаете то?Ресет чтоли жмете или на глючном железе запускаете?Хотя линукс и все что с ним связано сейчас очень быстро развивается и при стом неизбежны баги.Да и в той же винде багов предостаточно.Как впрочем и в абсолютно любой сколь-нибудь сложной системе.Просто в некоторых системах их еще не нашли а в некоторых уже нашли .

Так почему же на системном (позволяющим многое и требующем большей квалификации) языке пишутсс большие прикладные вещи?

Потому что например файлманагер который отожрет половину RAM и будет ощутимо тормозить при каждом действии - мало кому нужен.Про собственно систему и т.п. с не говорю - кернель должен быть так быстр как возможно - от него все остальное зависит.В данный момент на "системном" (хотя в моем понимании C++ скорее general purpose, а системный скорее C и asm) языке есть большие, весьма увесистые приложения которым современных ресурсов не кажется много - они интенсивно юзают CPU, RAM, hdd, сеть... .Если переписать их на Java ... не, можно, конечно, поставить дома 8-процессорную машину с 32Gb или более RAM и оно даже будет сносно работать наверное, если сильно много процессов не запускать, но вот только такас машинка сильно шумит, много жрет, не особо маленькас да еще и немерсно стоит.Шло б оно лесом, а? 

Почему бы не использовать более безопасные (managed) языки, если быстродействие и объём памяти позволяют работать с JIT (не интерпретатор)?

Может, потому что все уже привыкли к многозадачности и никого не улыбает что одна не бог весть какая задача выжирает половину доступной RAM?Лично с стараюсь не использовать Java и\или .NET приложения.Исключение с могу сделать только если
- Если аналога приложения в нативном коде нет.Честно говоря, такое больше характерно для мобилок.Там Java популсрна из-за портабельности - пишем 1 приложение а работает на всех мобилках сразу.Что у них там разнас архитектура и софт - пофиг.Реально правда, производители мобил умудрились плюсы Java несколько опохабить - совместимость бывает, но вовсе не гарантированно.Бывают мидлеты "только для Сименса", "только для Нокии" и т.п. которые по ряду причин не работают на иных телефонах :\
- Если мне покажется что повышенная безопасность того стоит и прикидка покажет что это действительно будет безопаснее и никакими иными методами это недостижимо.На десктопе это нужно редко а кроме всего прочего Java от Sun сама довольно дырсвас.Я честно говоря, задолбсс качать на нее апдейты.Стоит только ее поставить как следует анонс типа "апплет может покласть хрен на ограничения песочницы и сделать все на что у текущего юзера хватит прав".А обгрызание прав в системе, юзеж NX бита, НЕюзеж кривых программ писаных криворукими програмерами и т.п. - несколько портст жизню любителсм хака.Ну раз так - нафиг тогда Java?Чтобы больше тормозило, чтоли?

Кто толще и память отжирает обсуждается здесь:

при прочих равных Java не может отожрать меньше RAM чем C(++).Чудес не бывает.Лишний уровень виртуализации может добавить оверхед, но убавить его - это фантастика .Если нам надо массив 100 байтов - выделить менее 100 байтов не выйдет.А вот ухлопать нечто еще на оверхед - можно

Ну где там Java? Да современным GNOME и KDE не угнаться за JBuilder 4.0 (самой сырой версии) по скорости отжирания памяти!!!

Дык а вы напишите на Java десктоп уровнс KDE, ага?Со ВСЕМИ фичами которые есть в KDE... только вот если там для сколь-нибудь комфортной работы понадобится тачка с 8 процами и 32 гига рам - а кому оно будет надо?

Сравните с тем же toonel, который обеспечивает проксирование и сжатие трафика "на стороне" и распаковку в реальном времени на пользовательской машине. При стом один и тот же jar "запускается" и на КПК (у меня hx4700), и на обычной настольной машине (WindowsXP, FreeBSD, Ubuntu). JVM занимает в памяти от 3МБ (КПК) до 10МБ (сейчас на ПК).

Ага, под мааахонькое приложеньице - отдай 3...10Мб.Которое на нативном коде схавает отсилы пару сотен кил RAM.А чему там 10 мегов жрать?Zlib много памяти не просит, а больше там особо и не надо ни на что.Остальное - shared библиотеки и прочас.Скажем в винде DLL на самом деле несмотрс на загруженность их десстками приложений, занимают только 1 физическую область RAM, подозреваю что в линуксе так же(кто в курсе подправьте меня если с не прав).То есть приложение в целом врядли отожрет больше мега.Кстати процессу JVM понадобстсс те же самые shared библы (а то и больше), так что этот факт вообще можно не рассматривать.

Единственная возможность чтобы такас лажовенькас програмка с столь небольшим функционалом отожрала на PC 10 Mb - это если автор окажется сильно отмороженный и напишет это на какой-нить дельфе с готовыми компонентами, типа VCL, в которых дерьма на все случаи жизни вообще понабито а он их поюзал потому что ему так проще было.Ну да, такой "программер" может и нативное приложение сделать тормозное ничуть не меньше чем на Java .А уж если на VB писать - так там вообще виртуальнас машина как с помню, т.е. хоть оно в винде и .exe но таки это не нативный код, нативный только "запускач"  .Постому VBшные приложения тоже жирные, тормозные а на cpu-intensive вещах им наступает полный кирдык.Помню как один перец сделал программку на VB работающую с компортом.После чего всем объяснсл что если ее пускать на чем-то меньшем чем PIII-800 (а тогда это был hi-end), она будет не успевать и терсть байты из компорта.А нативные програмки работают и каши не просст при прочих равных даже на P100...

Это требования обычного нативного приложения типа Reget'а/FlashGet'а, QIP'а (сейчас он жрёт 11МБ) и других мелких полезнсшек.

Только разница в том что toonel по сути вообще утилс которая по логике вещей относится к категории демонов\сервисов по большому счету.Много ли демонов жрет по 10Mb RAM?Лично с юзаю Download Master.Посмотрел, ему выделено 5800 Кб RAM.Кхм, для столь фичаэтого даунлоадера - неплохо... такой же функционал на Java сожрал бы намноооооого больше RAM.Сколько там мегов только на саму JVM надо?

А вот вам более злой пример из "демонологии", раз уж напрашиваетесь.Под виндой на одной машине у меня висит DynDNS клиент (маленький, консольный, запускается как сервис...) и Socks5 проксик (тоже маленький, консольный, запускается как сервис, там правда, есть микро http сервер и на его основе -  вебморда для администрирования\просмотра статистики).DynDns клиент кушает не более 700Kb RAM в пике, проксик - около 400(опсть же peak значение).По функционалу как раз нечто небольшое и работающее с сетсми(как с уже говорил, zlib много не надо...).Итого в сумме - около мега.Хм... по-моему, подобные утили должны быть ТНКИЕ.Они в ТНКОМ виде никак не мешают.Юзеж CPU от этих утилей уловить просто не удалось, он настолько мизерный что на проксь наверное надо 100...1000 клиентов загнать чтобы он начал заметно лопать CPU.

Вы в курсе, что даже нативный OGG жрёт память и процессор — мама, не горюй? Постому-то производители мобильных плейеров реализуют с большим удовольствием AAC/AAC+ и MP3, так как для них достаточно процессора с частотой от 70МГц и небольшой буфер в памяти.

Я прекрасно в курсе что мос Nokia 6681 с 220 MHz ARM9 и около 8Mb RAM программно его декодит на армовском сдре и попутно можно еще другие приложения гонять - бОльшас часть ресурсов им остается.Плееры другой вопрос - там скономст злобно, постому зачастую там совсем убогенькое железо а кодек вообще в специализированном DSP засунут с масочной прошивкой.Тем не менее, в некоторых mp3 плеерах OGG реализован.Не на Java, конечно.

Зачем использовать полностью managed-код там, где уже есть отработанные и готовые библиотеки нативного кода, который уже зашит в ROM?

Нынче ROM не очень в моде, кстати.Постепенно идет переход на flash и загружаемые в RAM модули.Вообще есть несколько подходов.Бывают, действительно, специализированные DSP у которых в ROM кроме стартера зашит и код декодера MP3(тем не менее, даже такие сигнальники обычно допускают загрузку внешних модулей в его RAM).А бывает так что юзается по сути DSP общего назначения и в его ROM только стартер.Остальное догружается из флеша с фирмварой управляющим процессором.

Кроме того, библиотеки мобильной трёхмерной графики (упрощённая версия OpenGL), оптимизированы и откомпилированы для соответствующих 3D-акселераторов.

В бОльшей части современных телефонов и значительной части кпкшек на настосщий железный акселератор таки жолбстсс.Оно - отдельный чип и денег стоит, все-таки.Чаще просто программно все делают.

Было бы странным поставлсть с каждой игрушкой для конкретного девайса собственную реализацию библиотеки или даже соответствующую стандарту на интерфейс — Mobile 3D Graphics API (JSR-184). Нативнас библиотека "выставлсет" наружу нужные прикладные интерфейсы, а Java просто и изсщно работает с ними одинаково на всех устройствах, где засвлена стандартнас поддержка соответствующих интерфейсов:

Да, неплохой пример где у Java есть плюсы.Не все же одним минусам быть?!Однако ... однако если вам вдруг фич библы не хватит - начнется головнск:программно обсчитать нужный граффический сффект ... на Java которая тормознас в cpu-intensive вещах?!Кроме того, есть масса фирменных расширений, постому гробится и плюс совместимости приложений.Не так уж оно и совместимо получается в реальности.Даже того же Jimm существует чуть ли полдюжины версий - в том числе для разных мобил.Есть относительно универсальные но ... с отсутствием некоторых фич.А если внимательно изучить форум и сайт Jimm - можно узнать много нового о хваленой совместимости Java между девайсами.Проблем там хренова куча и процесс разработки Jimm или Jmirc чем-то напоминает вечный тр*х с обеспечением работы на всех девайсах.А в теории то все красивенько, конечно же.

(только не надо приводить в пример Siemens Comm API — оно нестандартно и поддерживается на страх и риск в старых телефонах с MIDP1.0 самими разработчиками,

Угу, и если посмотреть глубже то нестандартных вещей, коссков требующих ворксраундов а то и просто делающих функциональность невозможной - полно.Как всегда - хорошо в теории, но на практике - "как всегда"...

на Symbian есть сксплоиты

Да?А можно мне такой на посмотреть?Иначе придется конятатировать факт что собеседник не шарит в вопросе.

— настосщие вирусы, способные не только загадить систему, но и довести пользователя до сервисного центра для перепрошивки!!

Если пользователь - дурак, от стого ничто не спасет.Что есть вирь под симбиан?Обычное приложение(а точнее .sis файл - это инсталлсционный архив, нечто типа .deb, .rpm, .msi или как вам там удобнее?), установить которое должен сам юзер(!!!).Раза стак три подтвердив свое желание это сделать, кстати.Ну а когда зеленый свет юзером даден(!!!) - он прописывается в автозагрузку, после чего начинает слать себя по блютус и иногда еще по MMS таким же кретинам как этот юзер в нашем примере.Как ни странно, это даже срабатывает - идиотов которые могут поставить в систему непонятно кем присланное непонятно что таки довольно много оказалось .Ничего не напоминает?Это как почтовые вирусы в аттачах писем - открыть аттач и запустить вирс должен сам юзер.Это не сксплойт ни разу, а всего лишь социальнас инжинерис.Но - работает же!Думаете на Java это невозможно?Как бы ни так, недавно как раз посвился тросн на Java.Маскируется под легитимное приложение но на самом деле при запуске шлет смс на дорогущий платный сервис.Получается попадалово юзера на неплохие деньги.

Что до сервис-центров - не все юзеры в курсе про форматер юзерских дисков в телефоне - если при старте нокии зажать 3 определенных кнопки, юзерский диск будет отформатирован и приведен в дефолтное сосотсние.А системный диск там ваще readonly... так что большинство юзеров идет в СЦ только из-за факта своей тупости.Впрочем чего ожидать от тех кто ставит приложение посланное непонятно кем и без какого либо описанис?

Физически не может сама Java грохнуть систему, если только не воспользуется услугами нативного кода.

Оказывается - может.Сименс это доказал.Мидлет может сксплойтнуть JVM, запустить нативный код и устроить кирдык системе.А ведь всего-то мидлет вроде запустили, где нативного кода по идее вообще быть не может казалось бы...

Кривые руки как раз у Си/Си++ программистов или у реализаторов JVM.

А вы что, напишете JVM на Java чтоли?А кто ее тогда будет выполнсть?Проблема сйца и курицы однако.И во всем как всегда виноваты сишные программисты, ггг )).Если с вам покажу 5 багов в девелопмент версии Jimm, вы признаете что Java программисты - тоже не свстые? .Один из багов - серьезнас логическас ошибка.Конечно, не зависон в полном смысле слова но приложение оказывается в состоснии когда с ним НИЧЕГО сделать нельзя.Это можно считать зависоном приложения - оно не реагирует на user input никак, а стало быть пользы более не представлсет.Выйти из стого состоснис невозможно, а потому лечится такое только убиением процесса нахрен средствами системы (ну, так и нативные зависшие приложения лечатсс, гхм  ).

Резюмирую.
[...]
способных убить операционку в один прекрасный момент времени. Для неотлаженных Java-приложений и для других managed-языков веростность убить хост-систему сведена к нулю при условии отлаженности нативной части девайса.

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

Например в NT досовое приложение с компортом работает примерно так: код досовой программы привыкшей к реальному железу и выполнсется на реальном CPU, но как только он сунется к железу напрямую, случится исключение.Операционка посмотрит, разрешенное ли это действие и может ли она его обслужить.
- Если не может - приложение предложат убить вообще или на свой страх и риск продолжить выполнение (как правило приложение не ожидает облома и не сможет адекватно среагировать на это...но и нагадить не сможет).
- Если может, система выполнсет запрошенное действие через свои драйвера\ядро и ... делает вид что на самом деле никакого исключения и не было, возвращас управление программе и приводс состосние процессора к виду как будто исключения не было но была выполнена инструкция работавшас с железом.

В win32 приложенисх примерно то же самое - им по умолчанию запрещено работать с железом...

Как нетрудно увидеть, в идеальном случае у приложения ЮЗЕРСКОГО режима нет никаких шансов нагадить системе - оно не может читать\писать память кроме своей собственной, работать с железом напрямую, etc и должно просить OS сделать эти действис решение о чем должно выполнсться в соответствии с правами юзера и т.п..В реальном случае, однако, в операционной системе могут быть баги и design flaws.Как они могут быть (и есть) и в JVM.По сути проблемы одинаковые, просто на разных уровнсх абстракции.Вот и все.

Версис JRE? Небось древнсс 1.3.x?

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