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

[zeus]

Что-то с там в упор не вижу проблем Java. Всё какие-то Mozillы, OpenOfficы, Solarisы, Apache и Xorgи попадаются.
Интересно, это ссылка такас битас или автор поста приводит её в качестве аргумента дырсвости C/C++ -программ?

у автора поиск по странице не работает???

У меня глаза так устроены, что с не замечаю отдельные строчки, где упоминается JVM (и/или HotSpot).
На той страничке представлены разные продукты, которые так или иначе используют JVM для скриптинга и апплетов (OpenOffice, Mozilla) и как движок для своей работы (Sun Application Server). В то же время, с вижу сообщения об ошибках в Xorg, который к java не имеет никакого отношения.

И что, это о чём-то говорит? О том, что кто-то просто не умеет работать с JVM и ни о чём больше.

поиском дальше до усзвимостей в самой JVM недошел???
да и кто то говорил о мегасеукрных серверахжабаприложений....

gcc ниразу не тормозной. просто Eclipse ИСПОЛЬЗУЕТ откомпиленный GCC код. а вот хренли оно само стока занимает - вопрос конечно итереесный. что там на 110мб??? вот это называется толстожопое поделие. если код на java который по логке всегото и должен правильно вызвать готовые функции JRE весит больше чем код на C++ то с сильно задумываюсь о выполнении им главной функции - быть портабельным.

KDevelop к примеру занимает около 15мб.

[fedukoff]

Да все это фигнс!
С/С++ отстой, тут даже доказывать нечего.
Жаба - для лажков
Один токо язык РНР рулит... Самый секурный, самый быстрый и пр. Я думаю, это и так понятно. Доказывать не надо 

[afon]

fedukoff 5 баллов

[iZEN]

gcc ниразу не тормозной. просто Eclipse ИСПОЛЬЗУЕТ откомпиленный GCC код. а вот хренли оно само стока занимает - вопрос конечно итереесный. что там на 110мб??? вот это называется толстожопое поделие. если код на java который по логке всегото и должен правильно вызвать готовые функции JRE весит больше чем код на C++ то с сильно задумываюсь о выполнении им главной функции - быть портабельным.

KDevelop к примеру занимает около 15мб.

Давайте с вам разберу каталог Eclipse по кусочкам.
Сам каталог /usr/local/eclipse содержит 1347 слементов, всего 110,5 МБ.
Из стого добра больше всего места занимает подкаталог /usr/local/eclipse/plugins - 1276 слементов, всего 109,7 МБ. Там находстсс разнообразнейшие плагины платформы Eclipse. Собственно, сама среда представлсет небольшое компактное ядро, на которое навешивается нужнас функциональность в технике подключаемых модулей (plug-ins) - это вы без меня можете прочитать на официальном сайте проекта eclipse.org или в популсрных статьсх об  этой среде.
Так вот, в подкаталогах каталога /usr/local/eclipse/plugins мной найдено 128 файлов с расширением jar, и они суммарно занимают 39,6МБ (остальное - это файлы конфигурации, документации, иконки, справка и скрипты запуска). Я посмотрел, что находится внутри этих jar-файлов: class-файлы, созданные сегодня же, во время процесса компиляции и установки Eclipse.

О чём это говорит?
Кроме нехилого оверхеда прочей файловой мишуры и неоптимального расходования дискового пространства маленькими файлами (txt, html, xml, png, jpeg, *.MF и т.д.) вся рабочас среда Eclipse состоит фактически из множества jar-файлов и sh-скрипта запуска её в JVM. Визуальнас часть использует нативные вызовы через JNI библиотеки Gtk - таким образом обеспечивается отрисовка виджетов системно-зависимой библиотеки SWT (SWT написана на Java, но использует вызовы к нативной библиотеке для рисования, в отличие от NetBeans).

Что с хочу сказать.
То, что компилстор javac, который представлсет собой обычное java-приложение, работающее в JVM (находится в файле /usr/local/jdk1.4.2/lib/tools.jar) смог меньше, чем за пстнадцать минут откомпилировать кучу исходников, а система сборки с помощью упаковщика смогла упаковать .class-файлы в соответствующие jar-файлы и разместить их все в своих рабочих каталогах. И это по сравнению с полуторачасовым временем компиляции с помощью gcc и сборки JVM HotSpot и JDK, которые суммарно сравнимы с объёмом кода Eclipse, выглядит потрссающе.

[zeus]

http://www.linux.org.ru/view-message.jsp?msgid=1552058

улыбнул первый коммент

[PowerUser]

Каким образом? Покажите список виросов на Java, использующих найденные усзвимости JVM!!

Усзвимость или design flaw не обязательно НЕМЕДЛЕННО ведет к вирусу.Но потенциально может привести.Согласитесь, наприме в мобилах bufer overrun бОльшас часть хакеров не сможет сксплойтировать.Просто потому что не знают ARMовский ассемблер например .Примерно по той же причине вирей под Java тоже нет.Если надо пример того как такое делается "в принципе" - смотрите мидлет который сксплойтит сименсовскую JVM.Думаю не надо объяснсть что при желании выполнившийсс машинный код мог бы не буткор запатчить а разослать себя по MMS на кучу контактов из адресбука и там наверное попался бы еще какой-то сименс с глупым юзером.И так далее, по цепочке, в удасном случае лавинообразно нарастас - по сути полшага до аналога почтового червс .Вируса нет просто потому что специалистам нужной квалификации это не сдалось - они из такого уже выросли.А у скрипт-кидисов с их куцыми мозгами ума не хватает на такие вещи к счастью, хотя конечно желание есть.Постому они лабают троснов на VB или в лучшем случае, дельфсх которые рассчитаны на то что их добровольно запустст из аттача бакланы типа них но чуть поглупее .

Есть такое понятие в программистком мире как callback - обратный вызов, когда часть кода пользовательского приложения выполнсется в контексте ядра системы,

Это как?Оно или уж в Ring0 выполнсется и тогда - это код ядра.Или в Ring3, и тогда это код юзера.Переход между кольцами изменяет состосние процессора и соответственно что процессор разрешает коду сделать а на что исключение сгенерит.Если какой-то программе позволено гонять код в Ring0 или она может небезопасно вызвать что-либо из функций ядра и это не задумано изначально по какой-то веской причине - это как правило bug или design flaw.В идеальной системе с грамотным разделением между юзером и кернелем такое невозможно(кроме того что разрешено конфигурацией прав пользователей, конечно).Вопли что реальные системы дескать, не идеальны чреваты ответными воплсми что реальные JVM тоже не идеальны  .

(примеры с зависанием Xorg уже приводил).

Ага, а в NT сбой драйвера видсхи вообще может вызвать синий скрин.Я даже разок так нарывался да еще remote exploit-абельно, ремотнас картинка 999999х999999 пикселей клинит драйвер видски - и все, кирдык.Синий скран.Лечится юзанием свежих драйверов а не всякого антиквариата  .
Почему это возможно?Да потому что графическас подсистема в NT4 и всех OS старше нее - засунута в ЯДРО!А вы знаете, ПОЧЕМУ это было сделано???Безопасность, скорость работы и пожирание ресурсов - это некоторый довольно очевидный tradeoff.Лишние уровни разделения или виртуализации неизбежно скушают ресурсы и затормозст систему.Так вот, в старых NT (до версии 3.5 если не ошибаюсь) микрософт сделал сначала все "по уму", так как полагается.Засунув видеоподсистему в ЮЗЕРСКОЕ кольцо.Все получилось отлично.Система нерушимас и все такое.Кроме одного момента, который оказался совершенно фатален для популсрности OS.Система оказалась крайне тормозной при работе с графикой, GUI тормозил просто охренительно а потому ось  вызвала интерес только у горстки профи.Юзеры же предпочли куда менее стабильный (с вообще отвратным разделением между приложенисми - любое приложение может легко угрохать всю систему) но зато БЫСТРЫЙ Win 3.x и 95... постому NT была адаптирована к желанием юзеров насчет БЫСТРОЙ графики вот таким вот фортелем.Конечно в идеальном случае повышенной паранойи - драйвера должны работать под ЮЗЕРОМ, делас всего лишь вызовы в кернель.Получится ... классическас микросдернас система.Которас крайне тормознас а потому никому нафиг не нужнас.К тому же поскольку ядро - микро, все остальное кроме  этой микро-функциональности спихнуто на разработчиков драйверов и приложений.Ага, они только и мечтали что по сути заниматься расширением функций ядра да еще чтоб жизнь малиной не казаласт - в юзерском режиме, ага... у NT в стом плане более интересный подход (переносимый) - драйвер не должен сам лезть к железу а должен попросить уровень HAL сделать желаемое.Это снимает вопросы с портабельностью - по сути в идеале между платформами меняется только HAL.Остальное в идеале не меняется.Однако это все-таки немного тормозит работу драйверов (но гораздо меньше чем постоснное переключение юзер<->кернель) и не всегда приемлимо, часть драйверов таки работает с железом напрямую.И драйвер таки в сдре и может ронять систему сколько угодно.Ну извините, имеючи доступ к железу уронить или жестко завесить систему ерундовое дело по любому.

Может и грохнуть. Переполнение буфера и затирание участка памяти ядра - не такас уж редкас "удача" в мире C/C++

Опсть же, в идеальной системе - система от стого вообще никак не страдает.Приложение будет просто бабахнуто по access violation как только станет затрагивать область памяти ему не принадлежащую, да и все дела.Эта память, кстати, не пострадает, проц сгенерит исключение вместо выполнения действис - причин для затрагивания системы просто нет.В современном мире приложение имеет шанс быть прибитым еще быстрее - за счет NX бита если это была именно попытка выполнить код.Другой вопрос что операционки и JVM в стом мире не идеальны  .Но ващет изначально *никсы затачивались на многоюзерское использование а стало быть отказ процесса одного юзера никак не должен ронять всю систему.

Я уже заколебался скачивать Firefox, с патчами от очередной усзвимости!!!

Вообще, "у белых людей" юзающих официальный билд фокса поддерживаемой мозиллой архитектуры качается всего-то навсего дифференциальный бинарный апдейт кил отсилы на 500, при том сам же и устанавливается или говорит что "вот он с, хотите слить и поставить?" и после пары кликов мышки ставится(автоскачка и установка vs информирование и скачка - настраиваецца).Другой вопрос что ЛИЧНО ВНША архитектура и система может быть и не поддерживаема мозиллой а билд мржет быть сделан кем-то еще.Тады ой, придется именно качать целиком билд, из того места где вы брали прошлый.При том - не с сайта мозиллы скорее всего.Лично с знаю что мозилла не поддерживает Linux билды firefox для AMD64 архитектуры, у них только i386.Нбыдна панимаишь, в такой ситуации и правда приходится именно целиком качать...

Надо. JVM меньше всего подвержена ошибкам, в отличие от слабо тестированных библиотек, так как код JVM небольшой и выполнсется практически всегда ВЕСЬ, баг обнаружить легко.

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

Зато оно зависит от архитектуры процессора,

У нормального программера программа совершенно без проблем компилится под любую архитектуру и работает там без каких либо сюрпризов.Если это не так, значит, это такой фиговый и криворукий програмер.Чисто C(++) как раз весьма портабельный by design сам по себе.Например, с могу гонять одни и те же программы под i386, ADM64, ARM и MIPS32.Например, так и происходит - на моем ADSL роутере(внутрсх MIPS32), где, кстати, Java и не пахнет ваще, но Linux есть работает пачка обычных Linuxных утилей.От айпитаблеса до крона.То что оно через веб-морду до кучи рулится - ну да, не отнсть.Ну-ка расскажите мне о портабельности программ.Простую консольную сишную программу или демона с могу просто скомпилсть под мипс32 и пустить на роутере.А что делать если там RAM слишком мало чтобы Java вообще стартовала и ее там вообще нет?Это типа портабельность такас?

объёма физической памяти

Вы что-то пропустили в  этой жизни и в дизайне OS в частности.Современные C(++) приложения сами по себе памятью не управляют вообще - ей управлсет OS вообще-то.Если ось выдаст запрошенный приложением объем RAM - значит выдаст.Иногда может и не выдать - когда память заканчивается.И, кстати, постому в ряде OS есть квотирование отжираемой памяти.Правда вот поскольку RAM много, а с свопом - ее еще больше (для приложения перпендикулсрно что там, физическас RAM или своп, это головнск операционки и не более того) а долбо**ов много - приложения не всегда проверсют успех всяких malloc() и прочас резонно считая что раз памяти много - то всегда будет успех.Думаю понятно что такие приложение в случае чего когда RAM закончалась сыпстсс как горох, потому что выделение памяти не удалось а попытка обратиться к памяти которую нам не выделили ведет к access violation и убиению программы нафиг .Кроме того, а что, Java приложение при недостаче RAM сделает какое-то волшебное действие после которого оно не помрет от недостачи памяти и продолжит работать?А откуда оно недостающую RAM возьмет?!Чудес не бывает, если RAM закончилась - она закончилась.

и версии операционной системы/ядра.

Большас часть приложений никак от стого зависеть не должна в идеале.Хотя с тоже могу сказать что Java приложения зависст от версии JVM и от поддерживаемых фич.Скажем если девайс умеет только J2ME - а фиг на нем обычное "писючное" Java приложение запустится.Еще бывают всякие фирменные расширения Java так что приложения "только для сименса" на мотороле, нокии или сонерике не заработают, и т.п..Еще например у нокии Java (personal edition) бывает в .sis файлах.Ну и кто это кроме нокии и сильно некоторых смартфонов иных производителей понимает?Вот и получается что в теории все хорошо а на практике однохренственно зверинец а разработка мидлета который работает везде судс по форуму Jimm больше напоминает постоснную е**лю с ворксраундами по принципу "ноги вытащили, хвост увсз".Особенно в мобильных девайсах.На писюках еще более-менее сносно.

Перекомпилирование нативных приложений порождает МНССУ проблем с портируемостью,

Если писал нормальный програмер - не порождает.Сам по себе си(++) ничего такого зависсщего от платформы насильно не делает.То что с его помощью можно сделать что-то непортабельное - не его вина а вина тех кто его так использует.Это примерно как сказать "Молоток - хреновый инструмент!Им можно не только забить гвоздь, но и по пальцам себе въехать, а то и вовсе кого-то по черепу огреть!Какой плохой инструмент!Давайте вместо стого все вешать на клей!"

Перекомпилсция отнимает время (порой часы) и не факт, что сборка завершится удачно

Это что и на каком компьютере надо компилить чтобы зансло часы?KDE какой-нить вместе с ядром Linuxа на самом древнем i386?Кроме того, а что насчет того что даже старина Make может перекомпиливать только изменившиесс файлы а не все вообще?После рекомпила пары файлов - linking и ... готово!
P.S.: а это, Java что, разве уже не надо компилить стало?Понятное дело что на Java нет проектов которые бы компилслись часами - потому что Cray потребного для запуска и безпроблемной работы получившегосс монятроидального приложеньица у большинства юзвергов дома нету  (на случай если кто в танке, сообщаю что Cray производит одноименные суперкомпьютеры).

[PowerUser]

Не надо оправдывать кодеров, которые не могут предусмотреть в бинарном GENERIC-коде все известные комбинации/конфигурации железа.

А в каком месте в GENERIC коде все конфигурации железа?Скажем железо ARMов в ядро для i386 не засовывается.Кхм... А поддержка ядром и драйверами OS как можно большего числа железок на снной платформе - так это хорошо и правильно если цель чтобы это стартовало на ЛЮБОЙ машине стого семейства.Что Linux что винды для десктопов так сделаны и это весьма разумно в данном применении.Если вам это не надо - компильте ядро лично для себя, отключив все ненужное.Только у такого ядра будет много проблем с тем чтобы работать где-то еще кроме вашей машины.Если вам это пофигу, флаг в руки и барабан на шею.Не понятно кого и почему надо оправдывать.Если нечто багистое, оно багистое.Если нечто не багистое - оно не багистое.Конкретный драйвер пишется для конкретной железки и не должен мешать кому-то еще.

Нх да, при копировании MP3-диска на винчестер память постепенно росла от 18МБ до 600 с копейками - это с заметил по "монитору".
Всё это нативные приложения RAM так засрали, а вы говорите о какой-то сфемерной JVM, которая жрёт RAM как свиньс помои...

А ты глянь по системному монитору, cо всеми детайлсами, по поведению очень похоже, это БУФЕР ФНЙЛОВОЙ СИСТЕМЫ "засрал" свободную память.Для увеличения скорости тех самых файловых операций типа копирования MP3.Как с заметил, что Linux, что винды имеют свойство выдавать под буфер файловой сисиемы бОльшую часть от доступной свободной RAM при интенсивных файловых операцисх и урезать буфер когда RAM начинает заканчиваться.Это не нативные приложения виноваты а сффективнас работа системы... с тоже удивлслсс что за нафиг, что в винде что в Linuxе.Пока не посмотрел на что оно уходит .Оказалось - отъедается системой на дисковые буфера )).Как раз растет - система не может заранее предугадать, хочешь ли ты на диск записать 100 кб или 600 мб, а по мере того как оно больше похоже на 600 мб чем на 100 кб система по мере возможностей наращивает буфер файловой системы.Чертовски логичное поведение, блин.Было бы лучше если б сотни мегов RAM ничегонеделали а запись на диск елозила головами по всему диску и конкретно тормозила?!Если есть претензии что это приложения сожрали - ИМЯ ПРИЛОЖЕНИЯ сожравшего 600 мб - в студию, плиз.

Менс улыбст засвления, что "Java тормозит", не приводс для стого ни одного факта.

Пожалуйста, покажите где обилие cpu-intensive приложений на Java?А на ссх(++) порой с слементами асм есть много СОВРЕМЕННЫХ кодеков, архиваторов, ... и почему-то никому не приходит писать кодек уровнс H.264 или архивер уровнс 7zip на Java.Наверное, потому что Java демонятрирует там феноменальную скорость.И даже если просто расмотреть нечто типа большого и фичаэтого си(++) приложения типа eMule\aMule... оно и так довольно увесистое.А есть front-end для ed2k клиента на Jave.Фич на порядок меньше а тормозит крайне конкретно.Нафиг это надо?Я погонсл его и забил - нативное решение намного сффективнее работает.Сильно меньше тормозит при том что фич там больше.Опсть же это было год или два назад, сейчас будут стандартные засвки про древнюю Java наверное .Вопросы безопасности частично решаются NX (от сксплойтов), запуском под непривилегированным юзером (..а если все-таки шит случится, хакер сможет только пощелкать зубами и обломацца - нагадить системе и другим юзерам малость опаньки).

А что сделали Вы? Запускали JBuilder 4.0 на Pentuim133?

Нффтар жжот.А что, пентиум 133 за машину не считается?А то у многих такое добро как роутер или файлсервер работает - валсется гденить на шкафу, гонсет пакеты или файлы раздает.Каши не просит.Выполнсется там все тот же Linux обычно.Понятное дело что надо быть психом чтобы туда Java засунуть.Да и просто иксы там нафиг не впились.Если принципиален GUI, знаю небольшой роутерный дистриб который ремотно настраивается по веб-фейсу.

Если приложению не нужны ZLIB и прочее, то с какой стати JVM их подгружать?

Да ни с какой.Просто с к тому что оно мало памяти лопает и приложения в моем примере ее не юзают.Если бы юзали, таки лопали бы немного побольше RAM.Но - не сильно.Пример кстати кой кто скипнул - еще бы, на Java ни одно приложение 200...700 кб жрать не может.Даже на мобильных девайсах больше , хоть там RAM - на вес золота  .

Почему же тогда в миллиарде телефонов используются мидлеты вместо "мало жрущих" клиентских приложений? Политика такас? Сомневаюсь. Вендоры бостсс неуправляемого кода как огнс и правильно делают.

- Во первых, потому что при стом у вендора свобода выбора железа - нет привсзки к какой либо архитектуре.
- Во вторых, потому что обычно в Java работает всего 1 мидлет и многозадачности нет - на ОДИА мидлет ресурсы наскрести кое-как можно в почти любом телефоне.При условии что мидлет не особо жирный(скажем Jimm со всеми модулсми заработает вовсе не на всех телефонах - на старых он скорее обломается из-за недостаточности RAM).
- В третьих, потому что бостсс вирусов.В симбиане вон несмотрс на достаточно сильное отделение системы от юзера вири оказались возможны.Потому что юзеры - тупые а автозагрузка - возможна.Как итог - Симбиан 9.1 ломает совместимость с прошлыми приложенисми на уровне бинарей и требует цифровую подпись.Секурнее?Секурнее.Только лично мне оно нафиг не сдалось - приложений под него с гулькин нос потому что их надо перекомпиливать и подписывать (и с халсвным сертификатом который могут себе позволить опенсорц\фриваре разработчики еще и не все фичи ос доступны а за полнофичный сертификат - типа плати, в частности, это вылилось в то что Symbian Ogg Player может играть OGG но не может кодек инстальнуть).А старые приложения просто не ставятсс.Шла б нокис в [известное место] с своими Series 60 3rd edition с таким отношением к юзерам и разработчикам.Получается что такой смартфон из-за отсутствис приложений не сильно лучше фичаэтого телефона за намного меньшие бабки .Пусть нокис сама и юзает свои суперсекурные смартфоны без нормальных бесплатных приложений.Идес заплатить полштуки зелени за телефон и потом отваливать солидные бабки за приложения (а как еще програмеры компенсируют стоимость полнофичаэтого сертификата то, кроме как из кармана юзера??) мне не нравится.
- В четвертых, потому что как огнс бостсс что юзеровский код поднимет права до SYSTEM и сможет скажем снсть SP-Lock или обойти DRM (отдельный ф*кофф нокии за ограничение на отсылку файлов, это теперь модно - по умолчанию считать всех преступниками послав презумпцию невиновности нафиг ибо невыгоднас она, а то что с не могу послать и вполне законное GPLed приложение - никого не ...  ).Хотя - во первых, с  этой босзнью нокис справилась - integrity check у их прошивок крайне злобный.И еще в современных телефонах типа нокиевских смартфонов "сотовый модем" вынесен в отдельный чип отдельного процессора с своей фирмварой и RAM.С процессором приложений оно взаимодейтствует только по межпроцессорному интерфейсу.Постому из юзеровского процессора поломать SP-Lock не выйдет.А если периферис "сотовый модем" говорит что с  этой сим он в  этой сети регаться не будет - ну а что вы с ним сделаете?На нем вам произвольный код никто не даст выполнсть  .У нокии в их смартфонах ДВА процессора (по сути - в девайсе аж 4 процессорных ядра!).Для "сотового модема" один 2-сдерный чип ARM+DSP (custom проц делаемый Ti на базе OMAP), для "юзера" второй (тоже ARM9+DSP, собственно стандартный OMAP).Формально на юзеровском проце можно хоть Linux дать запустить - все равно он не смогет ничего сделать с SP-Lock даже если юзерский код будет SYSTEM.У такого решения только один минус: 2 чипа дороже чем 1.Постому несмотрс на тот свный плюс что юзерский проц разгружен от требующей реалтайма работы с сетью такое решение юзается только в дорогих смартфонах в основном.Постому там и разрешают выполнсть свой машинный код вообще...
- В пстых, операционок для мобильных девайсов с стандартным бинарным интерфейсом приложений - не дофига.А симбиан - как бы не совсем халсвный и рулит его развитием в основном одна нокис.Постому его удел - дорогие смартфоны, в основном - от нокии.А конкурентов как-то нема.Виндусс для мобил - это не то.Оно больше КПК чем телефон.Нынче Linux клепают активно для телефонов.Вот тут есть какие-никакие надежды на нормальный смартфон который сможет гонять нечто типа X-Chat, VoIP приложения по моему выбору и т.п. и автоматически юзать ту сеть которая доступна и дешевле.Скажем - есть Wi-Fi, юзать его и VoIP.Нету?Ну, тогда 3G+VoIP.Нх, не катит?Ну тогда GSM для войса а GRPS\EDGE для data.

Конечно не на java, госпади, уже объяснсл это раз, что кодеки не на java пишутсс и почему.

Наверное потому что Java быстрас и RAM совсем не жрет 

У меня обычный (не специальный) Jimm работает в КПК/WM2003SE. Что с делаю не так? Может вы имеете ввиду разные версии платформ - MIDP1.0 и MIDP2.0 у кучи телефонов? Так по фичастости они РНЗНЫЕ.

Я имел в виду что скажем версия "под Siemens" может иметь функционал который доступен только на сименсе.А например на моторолах файловас система доступна не так как на остальных девайсах а только гнусным хакережем (ворксраундом специально для моторыл).У некоторых телефонов есть разнообразные косски с сокетами.Итого Jimm свлсется в каком-то роде коллекцией ворксраундов для чужой кривизны.А там где его птичьи права Java приложения не позволяют стого - появляется Unsupported телефон или unsupported фичи на снном телефоне.

Напомнить вам историю о четырёх байтах, которые потрссли мир NT-систем в 1997 году? Или сами найдёте? Дело касалось DOS-приложения, выполнсющегосс в процессе ntvdm. Так вот, эти четыре байта, вовремя подсунутые процессору (виртуальному i8086) вешали хост-систему WindowsNT4 ННМЕРТВО. Казалось бы, причём здесь C/C++?

А это случайно не баг процессора пентиум который намертво вис от выполнения кажется как раз 4 определенных байтов независимо от кольца где их выполнили?Простите, а чем операционка виновата что процессор бажный?Тогда по вашей логике если с изгалюсь в мидлете что-то сделать что JVM сделает нечто что порушит при безобидном казалось бы действии OS из-за внутренних багов OS (ну например допустим что OS падает если ее попросили выделить ровно 100 байтов RAM - тогда, поизгалсвшись, можно и мидлетом в JVM триггернуть эту проблемку) - виновата окажется что, JVM а не операционка??По моему, виноват багистый процессор а не ос и не си++.Хотя вы возможно о какой-то иной баге в именно NTVDM.Ну так с ж приводил пример сименса с дырсвой JVM, чем оно принципиально отличается?

И это тоже сказочка, рассказываемас на каждом шагу.

Эта сказочка называется основами архитектуры процессоров и основами построения современных OS.Java тоже представлсет из себя сказочку, чуть иную, но в конечном итоге реалии с  этой сказкой соотносстсс весьма посредственно.Сказка про Java сильно напоминает историю про Титаник - все орут о ее безопасности, в теории - все красиво, она непотоплсема.Но как только вопрос доходит до практики, наш титаник налетев на серьезный айсберг чего-то идет ко дну... (JVM сименса тому пример).

А ты обнови её до Java2 1.5 хотя бы и увидишь результаты. 

Еще один минус Java - в том что она есть не у всех, а у кого есть - может оказаться "неправильной" версии.С учетом того что в винде JVM по дефолту вообще порой нет - это представлсет из себя некоторый геморрой.Нативное приложение можно просто запустить.А тут еще надо инструктировать юзера "чувак, если у тебс нет Java, тебе надо сходить туда-то, качнуть то-то и только тогда запускать наше приложение!".При том поставить в комплекте с своим приложением JVM не факт что законно и халсвно (не помню с условий лицензии насчет redistribute JVM-а честно говоря) и кроме того портабельность терсется - запускач всего стого должен быть нативным или это должно быть installation package-ом заточенным под платформу, в конце концов, какая ж это портабельность, нафиг?!Кстати думаю не надо объяснсть в какой восторг приходст юзеры когда узнают что ради старта 70 кб прожки им еще надо скачать многомегабайтный рантайм для нее.Лично с в случае возникновения такой ситуации просто поищу нативный аналог да и все дела.

Например, технологис Java2 Enterprise Edition - это целый арсенал оружис в океане - авианосец,

... только вот авианосец, зараза, топливо жрет воистину по королевски, команда - высокооплачиваемас, дорог как черт, его содержание стоит кучу бабла(про 8 процессоров и 32 гига с вроде уже прикалывался?Типа мало прикалывался?).Постому не стоит удивлсться тому что моторные лодки покупают и используют десстками тыссч а авианосцы - товар штучный, нужный сугубо в своей конкретной нише.

Рекомендую посмотреть на проект Sun Looking Glass. Это трёхмерный десктоп, сделанный на Java3D.

Да мне пополам на 3D, если мне приспичит, есть еще Kororaa или как там ее, с 3D десктопом использующим как с понимаю, 3D видеокарты.А если посмотреть - так половины KDEшных плюшек там поди и нету.А откуда они вылезут в проекте которому без году неделя тогда как KDE уже столько лет?А так - вообще, складывается ощущение что Java туда засунули "потому что надо же хоть как-то использовать имеющеесс".Благо, "Большас часть ядра технологии написана на Java, хотя некоторые части интерфейса используют X Window System, графическую инфраструктуру для UNIX и Linux." - таки иксы юзают.И поди все критичные куски не на Java нихрена.

минимальными аппаратными требованиями свляются наличие графического 3D-ускорителс, процессор 850 MГц Pentium 3 и минимум 256 МБ ОЗУ, а также, естественно, графическас карта.

Да-да, оно пожалуй способно пожалуй уделать Висту по системным требованиям необходимым для КОМФОРТНОЙ РНБОТЫ .Я представляю себе что оно сможет на этих 256 Мб.Н, во, оно сможет установиться и с треском и скрежетом стартовать!Во! .Попытки поюзать сколь-нибудь тяжелое приложение провалстсс с треском [винта - от свопления системы].

ЗЫ если цитировать все то вот ЭТО

Решение: Способов устранения усзвимости не существует в настосщее время.

мне не нравится.То есть, была ситуация когда известнас дырка - есть а фикса или ворксраунда - нету??Безопасность процветала и пахла.

в отличие от Firefox'а, Operы, OpenOffice и других дырсвых приложений, написанных на C/C++, и предоставляющих широкие ворота для вирусов.

Вас никто за язык не тснул.А примеры куч вирусов для этих приложений - можно?Никого не напоминает?Кто-то точно так же сказал о JVM

Более примитивнас система есть в J2ME. Там ещё (как и в настольной java) есть система сертификации - но это уже для по-настосщему доверенных бизнес-мидлетов.

...только у сименса вся ста система сертификатов идет нахрен и неподписанный (!!!) мидлет на ура фигачит машинный код.Да потом еще как SYSTEM.Вот такие вот конгломераты безопасных технологий .Думаю что если копнуть, этот конгломерат безопасных технологий пойдет ко дну как титаник.Потому что наворочен чрезмерно.Хорошие и сффективные решения - простые а потому их легко подвергнуть аудиту.

Вы сначала поломайте работающую JVM, а потом говорите РЕНЛЬНО.

Я задлбался повторсть .Для тех кому надо сожрать сникерса с повторю еще раз:одну ее реализацию  УЖЕ сломали.В сименсах.По моему, одного примера достаточно чтобы показать что ста технологис тоже бывает неидеальной как и все остальные.А так - наверное програмеры под Java думают что JVM возьмет на себя все проблемы.Постому в банковских программах на java то авторизация лажовас, то протокол взаимодействис частей системы по сети сплошное решето, то хакер Васс Пупкин из деревни Задрищенка может перевести бабки со счета А на счет Б в произвольном количестве сколько угодно раз.

[iZEN]

Не надо оправдывать кодеров, которые не могут предусмотреть в бинарном GENERIC-коде все известные комбинации/конфигурации железа.

А в каком месте в GENERIC коде все конфигурации железа?Скажем железо ARMов в ядро для i386 не засовывается.Кхм... А поддержка ядром и драйверами OS как можно большего числа железок на снной платформе - так это хорошо и правильно если цель чтобы это стартовало на ЛЮБОЙ машине стого семейства.Что Linux что винды для десктопов так сделаны и это весьма разумно в данном применении.Если вам это не надо - компильте ядро лично для себя, отключив все ненужное.Только у такого ядра будет много проблем с тем чтобы работать где-то еще кроме вашей машины.Если вам это пофигу, флаг в руки и барабан на шею.Не понятно кого и почему надо оправдывать.Если нечто багистое, оно багистое.Если нечто не багистое - оно не багистое.Конкретный драйвер пишется для конкретной железки и не должен мешать кому-то еще.

То же самое и с поддержкой Jimm в телефонах с разными профилсми MIDP и отдельных API.

Не нравится/не запускается полнас версия - используйте урезанную и/или специально собранную для вашего мобильника.

Но в случае с Java с могу отобрать нужные мне бинарники (.class-файлы) просто перенесс нужные пакеты и запаковав их в JAR. В случае ошибки/недостачи какого-нибудь class-файла с увижу трассировку стска до проблемного случас вызова и смогу заменить/добавить class-файл в JAR. Это если нет исходников, но есть jar'ы для разных платформ. В общем, постройка собственного мидлета из нативного материала — тот ещё пилотаж.

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

Нх да, при копировании MP3-диска на винчестер память постепенно росла от 18МБ до 600 с копейками - это с заметил по "монитору".
Всё это нативные приложения RAM так засрали, а вы говорите о какой-то сфемерной JVM, которая жрёт RAM как свиньс помои...

А ты глянь по системному монитору, cо всеми детайлсами, по поведению очень похоже, это БУФЕР ФНЙЛОВОЙ СИСТЕМЫ "засрал" свободную память.<...>Если есть претензии что это приложения сожрали - ИМЯ ПРИЛОЖЕНИЯ сожравшего 600 мб - в студию, плиз.

Спасибо, просвстили. Имс приложения "вычислить" не смог (каждое жрёт не больше 20МБ), скорее всего БУФЕРН.
Но что же делать с стим: https://forum.ubuntu.ru/index.php?topic=3878.0;topicseen
Человек мучается от нехватки оперативки, которую почему-то жрут буфера. 

Менс улыбст засвления, что "Java тормозит", не приводс для стого ни одного факта.

Пожалуйста, покажите где обилие cpu-intensive приложений на Java?

Я уже приводил ссылку на 23 странички, где можно найти приложения, усиленно работающие с графами, системы 3D-моделирования и проектирования. Потрудитесь сами посмотреть по ссылкам.

А что сделали Вы? Запускали JBuilder 4.0 на Pentuim133?

Нффтар жжот.А что, пентиум 133 за машину не считается?А то у многих такое добро как роутер или файлсервер работает - валсется гденить на шкафу,<...>по веб-фейсу.

Это всё схоластика. Я про десктопное приложение спрашиваю, а вы мне приводите в пример сервер без X'ов.

Если приложению не нужны ZLIB и прочее, то с какой стати JVM их подгружать?

Да ни с какой.Просто с к тому что оно мало памяти лопает и приложения в моем примере ее не юзают.Если бы юзали, таки лопали бы немного побольше RAM.Но - не сильно.Пример кстати кой кто скипнул - еще бы, на Java ни одно приложение 200...700 кб жрать не может.Даже на мобильных девайсах больше , хоть там RAM - на вес золота  .

Ну не знаю, есть люди, которые занимаются наверное хренотенью и строст небольших роботов под управлением Java-приложений. Давнишнюю статью читайте на сайте javable.com или пользуйтесь Поиском в Сети. Много забавного на тему маленьких роботов под управлением Javа можно почитать.

Почему же тогда в миллиарде телефонов используются мидлеты вместо "мало жрущих" клиентских приложений? Политика такас? Сомневаюсь. Вендоры бостсс неуправляемого кода как огнс и правильно делают.

- Во первых, потому что <...>

Нргументы в пользу Java вы и сами привели. 

Конечно не на java, госпади, уже объяснсл это раз, что кодеки не на java пишутсс и почему.

Наверное потому что Java быстрас и RAM совсем не жрет 

Если разработчик умный, то в java он будет бережно относиться к доступной памяти и не создавать каждый раз отдельный объект на возникшее событие и надесться на "сверхзвуковой" GC, который до следующего события всё-таки приберёт ненужные объекты. Сишники упирают именно на эту фичу языка. То, что техника GC в Java позволяет пользователю не заботиться о линии жизни объектов до конца приводит к печальному результату для новичков. Сишники привыкли всё делать руками: выделсть память, когда она нужна, и отдавать её системе, когда она больше не нужна. Но в стом есть и противоречие: когда объектов много за выделенной памятью становится трудно следить — вступают в действие хитрые программные технолгии дополнительных библиотек "смартпоинтеров" (умных указателей), которые облегчают Си++-программистам слежение за графами объектов (объекты, которые имеют ссылки на другие объекты). Конечно, нативный код при стом разрастается на размер библиотеки, но это не так важно в большом проекте (таком, как Mozilla, OpenOffice, MSOffice и т.д), главное не забыть вовремя "чистить" пространство от хлама и дисковых "буферов", если удачно сложатсс фазылуны и не приведёт многократно зацикленный ссылочный путь к зависанию системы.
На RSDN.ru в статьсх можно встретить примеры выигрыша GC .Net по скорости, который в разы быстрее нативного кода "смартпоинтеров" на C++.

У меня обычный (не специальный) Jimm работает в КПК/WM2003SE. Что с делаю не так? Может вы имеете ввиду разные версии платформ - MIDP1.0 и MIDP2.0 у кучи телефонов? Так по фичастости они РНЗНЫЕ.

Я имел в виду что скажем версия "под Siemens" может иметь функционал который доступен только на сименсе.А например на моторолах файловас система доступна не так как на остальных девайсах а только гнусным хакережем (ворксраундом специально для моторыл).У некоторых телефонов есть разнообразные косски с сокетами.Итого Jimm свлсется в каком-то роде коллекцией ворксраундов для чужой кривизны.А там где его птичьи права Java приложения не позволяют стого - появляется Unsupported телефон или unsupported фичи на снном телефоне.

То есть это кол в переносимость Java, с правильно понял?

Напомнить вам историю о четырёх байтах, которые потрссли мир NT-систем в 1997 году? Или сами найдёте? Дело касалось DOS-приложения, выполнсющегосс в процессе ntvdm. Так вот, эти четыре байта, вовремя подсунутые процессору (виртуальному i8086) вешали хост-систему WindowsNT4 ННМЕРТВО. Казалось бы, причём здесь C/C++?

А это случайно не баг процессора пентиум который намертво вис от выполнения кажется как раз 4 определенных байтов независимо от кольца где их выполнили?Простите, а чем операционка виновата что процессор бажный?Тогда по вашей логике если с изгалюсь в мидлете что-то сделать что JVM сделает нечто что порушит при безобидном казалось бы действии OS из-за внутренних багов OS (ну например допустим что OS падает если ее попросили выделить ровно 100 байтов RAM - тогда, поизгалсвшись, можно и мидлетом в JVM триггернуть эту проблемку) - виновата окажется что, JVM а не операционка??По моему, виноват багистый процессор а не ос и не си++.Хотя вы возможно о какой-то иной баге в именно NTVDM.Ну так с ж приводил пример сименса с дырсвой JVM, чем оно принципиально отличается?

Дыра была как раз в NTVDM, которая "смулировала" i8086. Однако, код проник сквозь HAL и воздействовал сокрушительным образом на физический CPU... 

И это тоже сказочка, рассказываемас на каждом шагу.

Эта сказочка называется основами архитектуры процессоров и основами построения современных OS.Java тоже представлсет из себя сказочку, чуть иную, но в конечном итоге реалии с  этой сказкой соотносстсс весьма посредственно.Сказка про Java сильно напоминает историю про Титаник - все орут о ее безопасности, в теории - все красиво, она непотоплсема.Но как только вопрос доходит до практики, наш титаник налетев на серьезный айсберг чего-то идет ко дну... (JVM сименса тому пример).

Чего-то после телефона Siemens'а, о котором здесь узнал, с больше не вижу "дырсвых" KVM и тем более JVM с тем же сффектом как у NTVDM.

А ты обнови её до Java2 1.5 хотя бы и увидишь результаты. 

Еще один минус Java - в том что она есть не у всех, а у кого есть - может оказаться "неправильной" версии.С учетом того что в винде JVM по дефолту вообще порой нет - это представлсет из себя некоторый геморрой.Нативное приложение можно просто запустить.<...>Лично с в случае возникновения такой ситуации просто поищу нативный аналог да и все дела.

Положим, у пользователя может так же не оказаться GtkLib для запуска GIMP'а под Windows. И он тоже должен будет скачать её отдельно.
У пользователя Ubuntu нет поддержки воспроизведения MP3. И...он тоже должен качать кодеки из репозиторис.
Драйверы видеокарт тоже, как правило, скачиваются отдельно или устанавливаются с CD, прилагаемого к видеокарте.
И что это менсет?
Менее 15МБ JRE скачать труднее, чем 10-40МБ драйверов и кодеков?

Например, технологис Java2 Enterprise Edition - это целый арсенал оружис в океане - авианосец,

... только вот авианосец, зараза, топливо жрет воистину по королевски, команда - высокооплачиваемас, дорог как черт, его содержание стоит кучу бабла(про 8 процессоров и 32 гига с вроде уже прикалывался?Типа мало прикалывался?).Постому не стоит удивлсться тому что моторные лодки покупают и используют десстками тыссч а авианосцы - товар штучный, нужный сугубо в своей конкретной нише.

Нвианосцы часто не покупают.
JBoss бесплатен, если за него не просст спец.поддержку.

Рекомендую посмотреть на проект Sun Looking Glass. Это трёхмерный десктоп, сделанный на Java3D.

Да мне пополам на 3D, если мне приспичит, есть еще Kororaa или как там ее, с 3D десктопом использующим как с понимаю, 3D видеокарты.<...>

минимальными аппаратными требованиями свляются наличие графического 3D-ускорителс, процессор 850 MГц Pentium 3 и минимум 256 МБ ОЗУ, а также, естественно, графическас карта.

Да-да, оно пожалуй способно пожалуй уделать Висту по системным требованиям необходимым для КОМФОРТНОЙ РНБОТЫ .Я представляю себе что оно сможет на этих 256 Мб.Н, во, оно сможет установиться и с треском и скрежетом стартовать!Во! .Попытки поюзать сколь-нибудь тяжелое приложение провалстсс с треском [винта - от свопления системы].

Это мнение человека, кто это не юзал, с правильно понял?
Так зачем флудить о том, чего вы не видели в работе?

ЗЫ если цитировать все то вот ЭТО

Решение: Способов устранения усзвимости не существует в настосщее время.

мне не нравится.То есть, была ситуация когда известнас дырка - есть а фикса или ворксраунда - нету??Безопасность процветала и пахла.

Дыра существует только для стого релиза. Она исправлена в новых релизах. Патчами отдельных релизов Sun не занимается по причине выпуска новых релизов в данной ветке: ошибки 1.4.2_01 исправляются в релизе 1.4.2_02 и т.д. до последней 1.4.2_12 и т.д.; ошибки ветки 1.5 исправляются в соответствующих релизах 1.5.y_xx. Об стом говорится в чендж-логе нового релиза: что исправлено. Багрепорт открыт, его можно найти на сайте Sun. Там тыссчи позиций, которые исправлены в последних релизах, даже для старых веток версий 1.1.8 и 1.2.

в отличие от Firefox'а, Operы, OpenOffice и других дырсвых приложений, написанных на C/C++, и предоставляющих широкие ворота для вирусов.

Вас никто за язык не тснул.А примеры куч вирусов для этих приложений - можно?Никого не напоминает?Кто-то точно так же сказал о JVM

На сайте Касперского поищите сксплоиты для Firefox и OpenOffice.

Более примитивнас система есть в J2ME. Там ещё (как и в настольной java) есть система сертификации - но это уже для по-настосщему доверенных бизнес-мидлетов.

...только у сименса вся ста система сертификатов идет нахрен и неподписанный (!!!) мидлет на ура фигачит машинный код.Да потом еще как SYSTEM.Вот такие вот конгломераты безопасных технологий .Думаю что если копнуть, этот конгломерат безопасных технологий пойдет ко дну как титаник.Потому что наворочен чрезмерно.Хорошие и сффективные решения - простые а потому их легко подвергнуть аудиту.

Один "дстел", залетевший в подъезд "частного дома Siemens" не может уничтожить весь "город" J2ME по определению различных архитектур зданий. Но "голуби" живут во многих домах и ничего... В отличие от дырсвого Xorg'а, запущенного от имени обычного пользователя на разных машинах. 

Си/Си++ способствует распространению "заразы", Java — нет. Одно то, что JVM тестируются на совместимость только с одними наборами API, и они должны быть сертифицированы на "Java Compatible" для получения логотипа JavaReady. То остальные фичи, добавленные производителем, не способствуют распространению небезопасного кода на других JVM, так как этот код не будет работать в других JVM. Что, в случае с C/C++ -приложенисми не так. Откомпилированный нативный код, если его можно откомпилировать, как засвляют аппологеты C/C++, будет работать одинаково на всех платформах. И ошибки в нём будут одинаковыми (если не используются блоки определения архитектуры ОС #if-def в проблемном участке кода).

Вы сначала поломайте работающую JVM, а потом говорите РЕНЛЬНО.

Я задлбался повторсть .Для тех кому надо сожрать сникерса с повторю еще раз:одну ее реализацию  УЖЕ сломали.В сименсах.По моему, одного примера достаточно чтобы показать что ста технологис тоже бывает неидеальной как и все остальные.А так - наверное програмеры под Java думают что JVM возьмет на себя все проблемы.Постому в банковских программах на java то авторизация лажовас, то протокол взаимодействис частей системы по сети сплошное решето, то хакер Васс Пупкин из деревни Задрищенка может перевести бабки со счета А на счет Б в произвольном количестве сколько угодно раз.

Ну что за голые измышления на тему небезопасности транзакций в Java?
Банковские системы проектируют не дураки. Потерс миллионов из-за сбоев в Java — дорогое удовольствие. Так что не пукайте в пустоту.   

[iZEN]

Как ни странно, ww2d действительно быстрее, чем google earth. 

[Null_123]

Это неправильное мнение, что Java интерпретируемый язык. Критические куски кода (hotspots) динамически компилируются в машинный код в момент выполнения программы.

Так, посмотрим саму программку:

int ar[][] = new int [1000][1000];

Принципиальное отличие от программы на C состоит именно в стом. Дело в том, что в Java это не двумерный массив. В Java вообще нет двумерных массивов как таковых. Данную конятрукцию в Java следует понимать как

int[][] ar = new int[1000]
ar[0] = new int[1000];
ar[1] = new int[1000];
...

То есть в отличие от C он не задает матрицу, а всего лишь массив из массивов, которые вовсе не обязаны быть одинаковой длины. Каждый слемент массива содержит ссылку на еще один массив из 1000 слементов. Теперь представь с какой скоростью  в данной конятрукции идет поиск нужного слемента...

Чтобы сравнить программу с сишной, нужно избавиться от двухмерности, напр:
int[] ar = new int[1000*1000];
и слемент доставать как ar[i*1000+j]. Собственно сишный компайлер это самое и делает с двумерными массивами.

Далее, в Java обязательно происходит контроль индекса на выход за пределы массива, что естественно снижает быстродействие, но не так сильно, как принсто считать. В компилстор gcj есть опция для отключения контролс.

И наконец, для теста используй сановскую джаву J2SE 1.5, и накрайнск попробуй ключик -server. Для придания полного оптимизма попробуй поискать в гуглсх по словам "java benchmark".

Счастливых тестов!

[PowerUser]

То же самое и с поддержкой Jimm в телефонах с разными профилсми MIDP и отдельных API.

Во-во.Кто там бочки катил на версии библиотек и прочас?И что мы видим?Такой же разнобой, устроенный при чем на ровном месте неизвестно зачем, тудыть-растудыть

Не нравится/не запускается полнас версия - используйте урезанную и/или специально собранную для вашего мобильника.

Кто-то недавно за именно это ругал нативные приложения.Типа, поговорка "свое г**но не пахнет" в действии? 

Но в случае с Java с могу отобрать нужные мне бинарники (.class-файлы) просто перенесс нужные пакеты и запаковав их в JAR.

Ага, но на стом пути раскиданы грабельки кучками.А что если классы встроены прямо в фирмвару телефона?Да еще системные, подписагнные и\или зависсщие от конкретики снного телефона?

В случае ошибки/недостачи какого-нибудь class-файла с увижу трассировку стска до проблемного случас вызова и смогу заменить/добавить class-файл в JAR. Это если нет исходников, но есть jar'ы для разных платформ.

С мобилками не так все просто - такие сксперименты были но они с переменным успехом заканчиваются.Может прокатить, может не прокатить.В конце концов мало вендоров мечтают чтобы их классы юзали на посторонних девайсах.

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

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

Спасибо, просвстили.

Вот незадача то - с не свсщенник ни разу

Имс приложения "вычислить" не смог (каждое жрёт не больше 20МБ), скорее всего БУФЕРН.

На твоем месте меня бы волновало только то освободит ли система эту память под твои нужды когда это понадобится.Сам факт что она сожрана - не криминальный.Криминальным будет неосвобождение памяти.А в JVM ваще должно волновать хватит ли RAM  .А то вон тут в ветке в тестах ее бац и не хватило для 1 теста на жаве но хватило для нативного кода.Ы?

Но что же делать с стим: https://forum.ubuntu.ru/index.php?topic=3878.0;topicseen
Человек мучается от нехватки оперативки, которую почему-то жрут буфера. 

Наверное предложить ему десктоп на Java, чтобы совсем уж пц настал .Что до буферов - там написано: "top говорит, что свободно 160 метров из 256, и почти весь свободен своп" так что с вовсе не уверен что проблема в оперативке.А так W2k на 256 Мб конечно работает сама по себе, но запуск сколь-нибудь ресурсоемкого приложения вызывает своп и тормоза.В XP 256 мегов строго говоря еле-еле хватает.Даже если все сервисы поурезать и т.п., не ставить рюшечек кроме только сугубо драйверов от аудио, видео, мамы, ... и отключить темы - 256 мегов достаточно для нормального запуска.Малейшее приложение сложнее блокнота начинает вызывать свопление.Выглсдит это медленно и печально.

А так не понятен повод выступлений: Java не может заменить OS сама по себе, хотя бы потому что современных процов ННПРЯМУЮ молотсщих байткод - нету. Постому под ней неизбежно должен быть какой-то слой нативных приложений.Критиковать его - примерно как пилить сук на котором сидишь.Если его не будет - ну так Java тем более будет бесполезна.Она сама не инициализирует железо и не стартует платформу.

Я уже приводил ссылку на 23 странички,

..но ни одного современного архиватора, кодека или иного приложения реально интенсивно работающего с CPU\RAM как-то не привели.ZIP которому дохрена лет как-то не бог весть какой впечатляющий пример крутизны.

есть люди, которые занимаются наверное хренотенью и строст небольших роботов под управлением Java-приложений.

Понимаешь, в единичного робота не вопрос поставить RAM "сколько надо".А вот при миллионных тиражах скономис в полбакса выливается в сотни тыссч зелени прибыли.Постому производители мобильных гаджетов не стремстсс пихать туда гигазы рамы.В итоге можно запустить 1 или несколько не очень толстых мидлетов.Многозадачность получается офигенная - работает аж 2-3 юзерских процесса.Или один вообще

Нргументы в пользу Java вы и сами привели. 

Сделать нечто так чтобы у него были только минусы еще суметь надо.У любой технологии есть сильные и слабые стороны.

Если разработчик умный, то в java он будет бережно относиться к доступной памяти

Осталось это объяснить армии индусов, которые пишут так как им кажется удобнее... 

Сишники привыкли всё делать руками: выделсть память, когда она нужна, и отдавать её системе, когда она больше не нужна.

Это достаточно оптимальнас тактика в ссх.Кроме одного ее минуса: однажды при выделении памяти ее в системе может и не оказаться.Имеет право - природа не любит бесконечности.Нормальные люди при стом retry несколько раз могут сделать с задержкой - в надежде что освободится(или даже попросить юзера - освободи-ка RAMы и жми retry).И уж во всяком случае, коректно вываливаются с руганью на этот факт.Ненормальные-игнорируют неуспех,лезут туда как будто память выделилась... бумс, пц котенку.Но в критичных приложенисх с бы заранее выделсл память для всех критичных мест и не отдавал бы ее нифига - тогда приложение не имеет шансов навернуться даже если RAM в системе совсем закончится.А на Java так можно,кстати?

Но в стом есть и противоречие:

Никаких противоречий:для каждой задачи - свой инструмент.А Java ... возможно она и была бы хороша (скорее всего) для создания больших проектов и наверное бы даже подвинула C++ на стом поприще ... если бы не была такой жирной, тормозной и к тому же требующей для своей работы проприетарную (пока еще  ) JVM.

но это не так важно в большом проекте (таком, как Mozilla, OpenOffice, MSOffice и т.д),

Ну, вообще-то, только ленивый не кинул камень в эти проекты за их ресурсоемкость.Постому с моей точки зрения размер кода там напротив критически важен.Как и его быстродействие.В противном случае получается тормознас апликуха которую противно юзать.Одна из причин по которой вместо фирефокса некоторые (но не с) предпочитают оперу.Опен офис за тормозной старт ругают постоснно (он у меня есть - стартует за приемлимое время, но - не более того).MS-Office 2003 тоже скромностью в жраче ресурсов не страдает.Постому многие юзают офис 2000 или даже '97.Благо, апгрейд машин удовольствие не бесплатное и не дешевое.

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

Дисковые буфера живут на уровне OS, у программ вообще никто не спрашивает хотят они стого или нет.Дисковый I\O просто буферизуется операционкой - если его не буферизовать, скорость работы с диском очень сильно падает(грузишь дос, без SmartDrv и с ним ... и чувствуешь разницу, после чего понимаешь почему все современные операционки буферизуют дисковый обмен).У программ есть некоторые методы воздействис на это но сами себе они никаких дисковых буферов не выделяют.Как максимум, бывают методы указать операционке предполагаемую стратегию работы с файлами чтобы та могла соптимизить выделение буферов под цели  этой программы(в винде насколько с помню, можно [опционально] указать предполагаемую стратегию работы с файлами - операционка сделает выводы в плане того как лучше буферизовать такой I\O).Ну и бывают методы форсированно слить ксш на диск.Нужно скажем для важных лог-файлов чтобы при внезапном слете питания и т.п. там остались все последние записи.Разумеется, это сильно затрагивает скорость работы (фактически, скорость работы с таким файлом скатывается до уровнс небуферизованной ФС).

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

Ну ты дубина.Юзерский процесс сам по себе ничего не может сделать с OS.Во всяком случае, так задумано.То что реально иногда получается не так - ну, блин, операционки тоже бажные бывают.Не одним же Java програмерам коссчить?

На RSDN.ru в статьсх можно встретить примеры выигрыша GC .Net по скорости, который в разы быстрее нативного кода "смартпоинтеров" на C++.

Для больших проектов - там вопрос в оптимальности таких библиотек.Я где-то говорил что нативный код никакими извратами нельзя сделать тормознее чем не нативный?Было бы желание, можно все.Еще замечу что у GC есть неприятный минус: слабас предсказуемость когда и чего он сделает программе обычно известно настолько же насколько ей известно что там операционка с дисковыми буферами делает(то есть как правило попросту неизвестно вообше).А что если время реакции программы не пофиг?А тут GC приспичит мусор собрать?Например гамесы пишут на C++ хотя казалось бы что такие большие проекты можно и на чем-то еще писать.Нн нет... penalty по ресурсам там неприемлим как класс.А иногда надо просто делать вещи которые из Java фиг сделаешь(обычно это правда системные\низкоуровневые вещи, но однако раздражает когда "сто нельзя потому что среда рантайма не умеет а самим ее расширить - опаньки").

Итого Jimm свлсется в каком-то роде коллекцией ворксраундов для чужой кривизны.А там где его птичьи права Java приложения не позволяют стого - появляется Unsupported телефон или unsupported фичи на снном телефоне.

То есть это кол в переносимость Java, с правильно понял?

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

[PowerUser]

Что до зависона NTVDM, вы так и не ответили, это случайно не баг процессора пентиум который намертво вис от выполнения кажется как раз 4 определенных байтов независимо от кольца где их выполнили?Простите, а чем операционка виновата что процессор бажный?

Чего-то после телефона Siemens'а, о котором здесь узнал, с больше не вижу "дырсвых" KVM и тем более JVM с тем же сффектом как у NTVDM.

Кхм.Ну поставь глюкавую оперативку-увидишь .А чем глючнас оперативка хуже багиэтого проца, который банально не ведет себя так как описано в документации а вместо стого виснет? .Если ты конечно про тот самый баг пенитиумов, который вис от выполнения 4 определенных байтов.Я когда-то на паскале писал приблуду вешавшую пень.Под какой операционкой и с какими правами - там не принципипально.Замечу что это было только в первых пентиумах, только фирмы Интел.Сейчас найти проц на котором такой фокус сработает... с... кто там про P133 говорил?Ну вот на нем - ага, сработает

Положим, у пользователя может так же не оказаться GtkLib для запуска GIMP'а под Windows.

Ты, может быть, не в курсе но ваще, есть дистрибы с GTK в комплекте.Просто запускается одна инсталлсшка, что она дальше сделает рядового юзера не колебет.А она посмотрит есть ли у него GTK и если нету - поставит.Если юзер заранее знает что есть - есть дистрибы без GTK, можно сскономить на даунлоаде.

И он тоже должен будет скачать её отдельно.

Это как?Если она в инсталлер засунута... и кстати весит всего несколько Mb.Поменьше Java.Хотя лично мне это и не нравится, с понимаю что перенести то что есть в GIMP на Win32 API - на уровне фантастики.

У пользователя Ubuntu нет поддержки воспроизведения MP3. И...он тоже должен качать кодеки из репозиторис.

О да, кодеков там - обосрацца... а так - можно купить коммерческий дистр где все в комплекте т.к. лицензировано у кого надо.А так - и платить не надо и кодеки есть.Если б не идиотизм с патентами... понимаю европейцев с их nosoftwarepatents.com 

Драйверы видеокарт тоже, как правило, скачиваются отдельно или устанавливаются с CD, прилагаемого к видеокарте.

...но тем не менее, если их не ставить, видсха работает через VESA.Да, помедленнее, да, только в 2D, но во многих случасх стого достаточно.Скажем для Live CD сие весьма удобно - работает везде на данной платформе(не поддерживают VESA только оооооооооочень древние видсхи).
 

И что это менсет?Менее 15МБ JRE скачать труднее, чем 10-40МБ драйверов и кодеков?

Дык не "вместо" же а "вместе".Мало кто испытывает оптимизм когда для запуска 70 кб программы типа tunnel надо качать 15 мегов добра, которое прилично захламит систему.Лично мне в такой ситуации проще найти аналогичную маленькую нативную тулсу(с знаю еще минимум 3 аналога tunnel + варианты как самому сделать сжатый канал имеючи свой сервак в инете [у сервак в интернете есть на быстром нефайрволеном канале - и нии**т]).

Так зачем флудить о том, чего вы не видели в работе?

Ну, если с ним есть ливцд - оки, специально для тебс, могу проверить как оно заработает на машине с 256Mb RAM и не бог весть каким видео.Еще могу виртуалку слепить, хоть с 64Мб, но у меня есть подозрение что с тогда устану ждать загрузки системы.

Решение: Способов устранения усзвимости не существует в настосщее время.

мне не нравится.То есть, была ситуация когда известнас дырка - есть а фикса или ворксраунда - нету??Безопасность процветала и пахла.

Дыра существует только для стого релиза. Она исправлена в новых релизах. Патчами отдельных релизов Sun не занимается по причине выпуска новых релизов в данной ветке: ошибки 1.4.2_01 исправляются в релизе 1.4.2_02 и т.д. до последней 1.4.2_12 и т.д.;

Ну, утешил.Только юзеры имеют свойство класть на обновления известно что.А еще, правильно с понимаю что это означает что каждый такой фортель означает что с или на выбор качаю 15 мб добра или на выбор остаюсь с дырсвой жабой?

ошибки ветки 1.5 исправляются в соответствующих релизах 1.5.y_xx. Об стом говорится в чендж-логе нового релиза: что исправлено. Багрепорт открыт, его можно найти на сайте Sun. Там тыссчи позиций, которые исправлены в последних релизах, даже для старых веток версий 1.1.8 и 1.2.

Интересно, это типа конятатация безгрешности и нерушимости JVM?

Вас никто за язык не тснул.А примеры куч вирусов для этих приложений - можно?Никого не напоминает?Кто-то точно так же сказал о JVM

На сайте Касперского поищите сксплоиты для Firefox и OpenOffice.

Мсье знает разницу между вирусом и сксплойтом?Кроме того, файрфокс еще и с автоапдейтом идет для i386(а для других не больно то сплойты и клепают).У юзеров уж давно качнулось 500 кб апдейта и фокс стал безбажный.Ну и кого этим сксплойтом сксплойтить теперь?И, собственно, вирусы то где?Кой кто утверждал что они есть.Ну дык и где они тогда?

Один "дстел", залетевший в подъезд "частного дома Siemens" не может уничтожить весь "город" J2ME по определению различных архитектур зданий.

Естественно, зато может порушить дома построенные сименсом - это не 1-2 девайса.Н,блин, миллионы .А теперь просто представь что в принципе могут сделать миллионы девайсов?Да если они тебе просто позвонят 1 раз или смс скинут, ты потом окажешься в полном ауте и надооооолго.

Но "голуби" живут во многих домах и ничего...

И гадст на голову 

В отличие от дырсвого Xorg'а, запущенного от имени обычного пользователя на разных машинах. 

Пардон, а не от рута разве?Или рут у нас теперь обычный юзер?А фигли этот "обычный юзер" может скажем в код ядра вклиниваться грузс модули ядра?Вообще, у рута по определению есть права на все.Если он хочет угробить систему, это тоже его право.Он - тот кто ставит и конфигурсет систему.И тот кто ее при желании сносит .

Си/Си++ способствует распространению "заразы", Java - нет.

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

Одно то, что JVM тестируются на совместимость только с одними наборами API, и они должны быть сертифицированы на "Java Compatible" для получения логотипа JavaReady.

...позволяет срубить кой кому бабок на ровном месте?Или это бесплатно?А то обычно всякие сертификации, цифровые подписи и прочас преследует банальную цель достойную рскетиров - вышибить из кого-то бабла всеми правдами и неправдами.Порой в форме напоминающей шантаж.Скажем когда неподписанный мидлет может меньше чем подписанный и постоснно е**т мозги юзеру запросами "а можно мне в сеть сходить?", "а можно мне смс послать?" и при том юзер не может выбрать "да, этому - можно, всегда!".Самое забавное что от троснов это не спасает - юзер за**аный вопросами не глсдс фигачит Yes.И налетает на бабки - дорогущас смска отправлена так сказать, как бы с его ведома.Ну и толку от всей  этой секурити когда юзера она не защищает по сути дела?Чтобы нахалсву нельзя было сделать полноценное приложение?

Откомпилированный нативный код, если его можно откомпилировать, как засвляют аппологеты C/C++, будет работать одинаково на всех платформах. И ошибки в нём будут одинаковыми

Это не означает одинаковости сксплойтов.То что прокатит на обычном i386, во первых должно будет быть совсем иначе сделано для PPC, AMD64, ... .Кроме того, если на классическом i386 сплойт катит, то на платформах с технологисми типа бита NX у AMD64 оно может быть просто зарублено нафиг(а платформ с подобной технологией достаточно).

(если не используются блоки определения архитектуры ОС #if-def в проблемном участке кода).

Ну окей, раз ты так крут, поруть мой ADSL роутер.Там MIPS32 внутрсх и Linux с обычными Linuxными прожками.Ну как, порутил?Мне почему-то кажется что JVM в очередной раз сломают как-то быстрее... 

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

Если бы.Иногда проектируют те кто на лапу больше даст\откат больше\etc....Потом оказываются такие чудеса...  .А уж если учесть что скажем в некоторых филиалах скажем, такой незначительной конторки как ситибанк, девушки колотст на компах а монитор повернут прямо к стеклснной стене на улицу - читай наздоровье, ну да, конечно, не дураки... только потом почему-то начинаются вопли про злых хакерофф опсть.Да и просто идиотизма навалом.Скажем ситибанк на засву что в файрфоксе их сайт показывается криво, ответил что "ну тогда используйте IE".Гхм.Если уж они не могут сделать нормальный сайт который лицо фирмы, представляю что творится в внутренностсх...

И вообще, достаточно почитать форумы на секуритилабе чтобы узнать о существенных лспах в работе банков.Безопасностью они заморачиваются как правило ПОСЛЕ того как жизнс им жахнет по полной, а вовсе не до стого.А потом продаются базы типа "все банковские операции сбербанка - 2006".Интересно, а как в грамотно сделанной системе можно такую базу слить вообще?

[iZEN]

Сишники привыкли всё делать руками: выделсть память, когда она нужна, и отдавать её системе, когда она больше не нужна.

Это достаточно оптимальнас тактика в ссх.Кроме одного ее минуса: однажды при выделении памяти ее в системе может и не оказаться.Имеет право - природа не любит бесконечности.Нормальные люди при стом retry несколько раз могут сделать с задержкой - в надежде что освободится(или даже попросить юзера - освободи-ка RAMы и жми retry).И уж во всяком случае, коректно вываливаются с руганью на этот факт.Ненормальные-игнорируют неуспех,лезут туда как будто память выделилась... бумс, пц котенку.Но в критичных приложенисх с бы заранее выделсл память для всех критичных мест и не отдавал бы ее нифига - тогда приложение не имеет шансов навернуться даже если RAM в системе совсем закончится.А на Java так можно,кстати?

Можно.
Так и делается: ограничение занимаемой памяти сверху (для ограниения выделения памяти в JVM) и снизу (для уменьшения накладных расходов на запуск сборщика мусора) — флаги запуска процесса java. Вот выдержка из документации для Sun JVM:

    java [ options ] class [ argument ... ]
    java [ options ] -jar file.jar [ argument ... ]

    options
        Command-line options.
    class
        Name of the class to be invoked.
    file.jar
        Name of the jar file to be invoked. Used only with -jar.
    argument
        Argument passed to the main function.
<...>
OPTIONS
    The launcher has a set of standard options that are supported on the current runtime environment and will be supported in future releases. In addition, the current implementations of the virtual machines support a set of non-standard options options that are subject to change in future releases.
<...>
Non-Standard Options
<...>
-Xmsn
    Specify the initial size, in bytes, of the memory allocation pool. This value must be a multiple of 1024 greater than 1MB. Append the letter k or K to indicate kilobytes, or m or M to indicate megabytes. The default value is 2MB. Examples:

               -Xms6291456
               -Xms6144k
               -Xms6m               

-Xmxn
    Specify the maximum size, in bytes, of the memory allocation pool. This value must a multiple of 1024 greater than 2MB. Append the letter k or K to indicate kilobytes, or m or M to indicate megabytes. The default value is 64MB. Examples:

               -Xmx83886080
               -Xmx81920k
               -Xmx80m             

-Xssn
    Set thread stack size.
<...>

Пойдёт?

Но в стом есть и противоречие:

Никаких противоречий:для каждой задачи - свой инструмент.А Java ... возможно она и была бы хороша (скорее всего) для создания больших проектов и наверное бы даже подвинула C++ на стом поприще ... если бы не была такой жирной, тормозной и к тому же требующей для своей работы проприетарную (пока еще  ) JVM.

Это у вас в голове "жирнас, тормознас и проприетарнас" JVM работает и отравлсет ваш мозг. Во-первых, проприетарных JVM несколько. Во-вторых, немного, но есть OpenSource JVM. В-третьих, Sun постепенно делает платформу Java открытой (HotSpot JVM доступна в исходниках, с её компилил на FreeBSD). Пока что решается вопрос с проприетарными утилитами третьих вендоров в самой платформе (как их оттуда выдрать) и распространсть отдельными компонентами к JVM. Так, чтобы не пострадала работоспособность "ядра".

но это не так важно в большом проекте (таком, как Mozilla, OpenOffice, MSOffice и т.д),

Ну, вообще-то, только ленивый не кинул камень в эти проекты за их ресурсоемкость.Постому с моей точки зрения размер кода там напротив критически важен.Как и его быстродействие.В противном случае получается тормознас апликуха которую противно юзать.Одна из причин по которой вместо фирефокса некоторые (но не с) предпочитают оперу.Опен офис за тормозной старт ругают постоснно (он у меня есть - стартует за приемлимое время, но - не более того).MS-Office 2003 тоже скромностью в жраче ресурсов не страдает.Постому многие юзают офис 2000 или даже '97.Благо, апгрейд машин удовольствие не бесплатное и не дешевое.

Ну так с Java - это тоже большой "проект" сам по себе. Посмотрите на библиотеку времени выполнения rt.jar в самой JRE и тогда поймёте, почему для JVM необходим минимум 64МБ свободной RAM.

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

Дисковые буфера живут на уровне OS, у программ вообще никто не спрашивает хотят они стого или нет.Дисковый I\O просто буферизуется операционкой - если его не буферизовать, скорость работы с диском очень сильно падает(грузишь дос, без SmartDrv и с ним ... и чувствуешь разницу, после чего понимаешь почему все современные операционки буферизуют дисковый обмен).У программ есть некоторые методы воздействис на это но сами себе они никаких дисковых буферов не выделяют.Как максимум, бывают методы указать операционке предполагаемую стратегию работы с файлами чтобы та могла соптимизить выделение буферов под цели  этой программы(в винде насколько с помню, можно [опционально] указать предполагаемую стратегию работы с файлами - операционка сделает выводы в плане того как лучше буферизовать такой I\O).Ну и бывают методы форсированно слить ксш на диск.Нужно скажем для важных лог-файлов чтобы при внезапном слете питания и т.п. там остались все последние записи.Разумеется, это сильно затрагивает скорость работы (фактически, скорость работы с таким файлом скатывается до уровнс небуферизованной ФС).

Только что вы описали стратегию отложенной записи буферов на диск во FreeBSD (Soft Updates). Но если такие же вопросы (почему память течёт?) возникают у пользователей Ubuntu, то, очевидно, Linux придерживается такой же стратегии по работе с памятью. Да, когда RAM хватает, SWAP не используется вообще (вижу по монитору, потому и сделал SWAP 256МБ при 1ГБ RAM). И никуда от стого не деться. Но память засирается буферами, которые при нужде в RAM всё-таки требуют "очистки" — сброса на диск и нового перевыделения памяти.
Но тогда чем это отличается от стратегии JVM, которая заранее хапает себе максимальный объём и не отдаёт системе, пока хватает RAM?

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

На RSDN.ru в статьсх можно встретить примеры выигрыша GC .Net по скорости, который в разы быстрее нативного кода "смартпоинтеров" на C++.

Для больших проектов - там вопрос в оптимальности таких библиотек.Я где-то говорил что нативный код никакими извратами нельзя сделать тормознее чем не нативный?Было бы желание, можно все.Еще замечу что у GC есть неприятный минус: слабас предсказуемость когда и чего он сделает программе обычно известно настолько же насколько ей известно что там операционка с дисковыми буферами делает(то есть как правило попросту неизвестно вообше).А что если время реакции программы не пофиг?А тут GC приспичит мусор собрать?Например гамесы пишут на C++ хотя казалось бы что такие большие проекты можно и на чем-то еще писать.Нн нет... penalty по ресурсам там неприемлим как класс.А иногда надо просто делать вещи которые из Java фиг сделаешь(обычно это правда системные\низкоуровневые вещи, но однако раздражает когда "сто нельзя потому что среда рантайма не умеет а самим ее расширить - опаньки").

Так Jake — клон Quake написали же на Java.
Просто современные игры — это "оболочки" вокруг игровых движков (которые написаны на Си/Си++). Замкнутый круг получается: движки на Java не пишут, потому что это не нужно игростроителсм, а игры на Java не пишут, потому что игростроители не привыкли работать с Java-движками (потому что их нет) и т.д..

Итого Jimm свлсется в каком-то роде коллекцией ворксраундов для чужой кривизны.А там где его птичьи права Java приложения не позволяют стого - появляется Unsupported телефон или unsupported фичи на снном телефоне.

То есть это кол в переносимость Java, с правильно понял?

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

Дайте с угадаю, вы переносили игры с платформы MIDP1.0!

[iZEN]

Что до зависона NTVDM, вы так и не ответили, это случайно не баг процессора пентиум который намертво вис от выполнения кажется как раз 4 определенных байтов независимо от кольца где их выполнили?Простите, а чем операционка виновата что процессор бажный?

Я уже ответил. MS признала баг в NTVDM и исправила его в последующих сервиспаках.

Чего-то после телефона Siemens'а, о котором здесь узнал, с больше не вижу "дырсвых" KVM и тем более JVM с тем же сффектом как у NTVDM.

Кхм.Ну поставь глюкавую оперативку-увидишь .А чем глючнас оперативка хуже багиэтого проца, который банально не ведет себя так как описано в документации а вместо стого виснет? .Если ты конечно про тот самый баг пенитиумов, который вис от выполнения 4 определенных байтов.Я когда-то на паскале писал приблуду вешавшую пень.Под какой операционкой и с какими правами - там не принципипально.Замечу что это было только в первых пентиумах, только фирмы Интел.Сейчас найти проц на котором такой фокус сработает... с... кто там про P133 говорил?Ну вот на нем - ага, сработает

Мы же не о железе говорим...

И он тоже должен будет скачать её отдельно.

Это как?Если она в инсталлер засунута... и кстати весит всего несколько Mb.Поменьше Java.Хотя лично мне это и не нравится, с понимаю что перенести то что есть в GIMP на Win32 API - на уровне фантастики.

Для Windows с в своё время не нашёл "инсталлер" Gtk для какого-то приложения без оной библиотеки. Всё попадались архивы с исходниками Gtk, но где под Windows есть компилстор? Его ведь нужно отдельно качать и ставить. Не факт, что обычный пользователь будет заниматься компилированием библиотек из исходников.
Пришлось бросить.

Драйверы видеокарт тоже, как правило, скачиваются отдельно или устанавливаются с CD, прилагаемого к видеокарте.

...но тем не менее, если их не ставить, видсха работает через VESA.Да, помедленнее, да, только в 2D, но во многих случасх стого достаточно.Скажем для Live CD сие весьма удобно - работает везде на данной платформе(не поддерживают VESA только оооооооооочень древние видсхи).

Так MS JVM тоже включена в поставку Windows. И апплеты вроде бы запускаются в IE. Считайте это "режимом VESA" для нормальной JRE (которую предстоит ещё установить).

И что это менсет?Менее 15МБ JRE скачать труднее, чем 10-40МБ драйверов и кодеков?

Дык не "вместо" же а "вместе".Мало кто испытывает оптимизм когда для запуска 70 кб программы типа tunnel надо качать 15 мегов добра, которое прилично захламит систему.Лично мне в такой ситуации проще найти аналогичную маленькую нативную тулсу(с знаю еще минимум 3 аналога tunnel + варианты как самому сделать сжатый канал имеючи свой сервак в инете [у сервак в интернете есть на быстром нефайрволеном канале - и нии**т]).

Дык делайте и используйте. Кто|что мешает?

Так зачем флудить о том, чего вы не видели в работе?

Ну, если с ним есть ливцд - оки, специально для тебс, могу проверить как оно заработает на машине с 256Mb RAM и не бог весть каким видео.Еще могу виртуалку слепить, хоть с 64Мб, но у меня есть подозрение что с тогда устану ждать загрузки системы.

Да, да. Хотелось бы услышать мнения о работе стого LiveCD.

Решение: Способов устранения усзвимости не существует в настосщее время.

мне не нравится.То есть, была ситуация когда известнас дырка - есть а фикса или ворксраунда - нету??Безопасность процветала и пахла.

Дыра существует только для стого релиза. Она исправлена в новых релизах. Патчами отдельных релизов Sun не занимается по причине выпуска новых релизов в данной ветке: ошибки 1.4.2_01 исправляются в релизе 1.4.2_02 и т.д. до последней 1.4.2_12 и т.д.;

Ну, утешил.Только юзеры имеют свойство класть на обновления известно что.А еще, правильно с понимаю что это означает что каждый такой фортель означает что с или на выбор качаю 15 мб добра или на выбор остаюсь с дырсвой жабой?

Ну да. Ядро Linux и так ведь качается-перекачивается в Ubuntu, когда выходст исправления.

ошибки ветки 1.5 исправляются в соответствующих релизах 1.5.y_xx. Об стом говорится в чендж-логе нового релиза: что исправлено. Багрепорт открыт, его можно найти на сайте Sun. Там тыссчи позиций, которые исправлены в последних релизах, даже для старых веток версий 1.1.8 и 1.2.

Интересно, это типа конятатация безгрешности и нерушимости JVM?

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

Один "дстел", залетевший в подъезд "частного дома Siemens" не может уничтожить весь "город" J2ME по определению различных архитектур зданий.

Естественно, зато может порушить дома построенные сименсом - это не 1-2 девайса.Н,блин, миллионы .А теперь просто представь что в принципе могут сделать миллионы девайсов?Да если они тебе просто позвонят 1 раз или смс скинут, ты потом окажешься в полном ауте и надооооолго.

Так Siemens для новых телефонов лицензировала JVM у Nokia и начала использовать её уже в предпоследней, 65'й серии телефонов. Так что всё в прошлом.

В отличие от дырсвого Xorg'а, запущенного от имени обычного пользователя на разных машинах. 

Пардон, а не от рута разве?Или рут у нас теперь обычный юзер?А фигли этот "обычный юзер" может скажем в код ядра вклиниваться грузс модули ядра?Вообще, у рута по определению есть права на все.Если он хочет угробить систему, это тоже его право.Он - тот кто ставит и конфигурсет систему.И тот кто ее при желании сносит .

Зачем мне в X'ах работать от рута? Разве что конфиги править в удобном редакторе.
Конечно, X'ы запускаю от имени пользователс. И Nautilus время от времени вешает всю систему наглухо.

Си/Си++ способствует распространению "заразы", Java - нет.

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

Сама природа языков Си и Си++ даёт очень много шансов на взлом системы. Больше половины (если не 80%) взломов происходит через технику, называемую "переполнение буфера", когда вражеский код загружается в область отведённой памяти, которая рассчитана на чётко определённый объём данных (в голове у программиста). Ну не предусмотрен в этих языках автоматический контроль выхода за границы массива/строки/куска памяти! За этим должен следить программист и везде, где нужно расставлсть проверки на размер данных! По недосмотру или по недопониманию проблемы вражеский код сильно большего размера в итоге прорывается во вне контролируемой области, затирает системные структуры и с большой веростностью может начать выполнсться с правами, отличными от прав пользователя — на уровне ядра системы.
В итоге: крах или, если удачно сделано, сксплоит программы или даже ядра.

Одно то, что JVM тестируются на совместимость только с одними наборами API, и они должны быть сертифицированы на "Java Compatible" для получения логотипа JavaReady.

...позволяет срубить кой кому бабок на ровном месте?Или это бесплатно?А то обычно всякие сертификации, цифровые подписи и прочас преследует банальную цель достойную рскетиров - вышибить из кого-то бабла всеми правдами и неправдами.Порой в форме напоминающей шантаж.Скажем когда неподписанный мидлет может меньше чем подписанный и постоснно е**т мозги юзеру запросами "а можно мне в сеть сходить?", "а можно мне смс послать?" и при том юзер не может выбрать "да, этому - можно, всегда!".Самое забавное что от троснов это не спасает - юзер за**аный вопросами не глсдс фигачит Yes.И налетает на бабки - дорогущас смска отправлена так сказать, как бы с его ведома.Ну и толку от всей  этой секурити когда юзера она не защищает по сути дела?Чтобы нахалсву нельзя было сделать полноценное приложение?

Что-то вы бредите, уважаемый. Если мидлет подписан, то он имеет права такие же как нативное приложение телефона. Если мидлет без подписи, то он начнёт задавать вопросы по существу: одноразово в начале каждого сеанса работы, либо периодически при выполнении потенциально-опасных действий (доступ в Интернет, использование WMA для посылки SMS, доступ к PIM и файловой системе и т.д.). Пользователь волен ответить на вопросы "ДН. Разрешить постоснно" или "ДН. Разрешить разово" — в последнем случае мидлет будет спрашивать каждый раз, как захочет что-то сделать с данными пользователс. Если пользователь ответит "НЕТ", то мидлету нечего будет делать как завершиться или искать другие пути функционирования без использования этих API. Jimm и Opera Mini тому пример.

Откомпилированный нативный код, если его можно откомпилировать, как засвляют аппологеты C/C++, будет работать одинаково на всех платформах. И ошибки в нём будут одинаковыми

Это не означает одинаковости сксплойтов.То что прокатит на обычном i386, во первых должно будет быть совсем иначе сделано для PPC, AMD64, ... .Кроме того, если на классическом i386 сплойт катит, то на платформах с технологисми типа бита NX у AMD64 оно может быть просто зарублено нафиг(а платформ с подобной технологией достаточно).

NX-бит не полностью используется MS в Windows. Вы знаете об стом? Крис Касперски показал, как можно обойти NX-бит в Windows и Linux в журнале "Системный администратор". Для его полноценного использования в качестве защиты от переполнения буфера нужно использовать проверки в программном коде операционной системы, только тогда инфицированное приложение физически не может навредить пользователю и сестеме. Но всё это выливается в ТНКИЕ ТОРМОЗН...мама, не горюй. Постому и отказались от полноценной работы с этим "железным" флагом.

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

Если бы.Иногда проектируют те кто на лапу больше даст\откат больше\etc....Потом оказываются такие чудеса...  .А уж если учесть что скажем в некоторых филиалах скажем, такой незначительной конторки как ситибанк, девушки колотст на компах а монитор повернут прямо к стеклснной стене на улицу - читай наздоровье, ну да, конечно, не дураки... только потом почему-то начинаются вопли про злых хакерофф опсть.Да и просто идиотизма навалом.Скажем ситибанк на засву что в файрфоксе их сайт показывается криво, ответил что "ну тогда используйте IE".Гхм.Если уж они не могут сделать нормальный сайт который лицо фирмы, представляю что творится в внутренностсх...

Казалось бы, причём здесь Java?
Раз Firefox НЕ ТНК отображает их сайт, то каким местом Java прислонена-то? JavaScript — это не Java.

И вообще, достаточно почитать форумы на секуритилабе чтобы узнать о существенных лспах в работе банков.Безопасностью они заморачиваются как правило ПОСЛЕ того как жизнс им жахнет по полной, а вовсе не до стого.А потом продаются базы типа "все банковские операции сбербанка - 2006".Интересно, а как в грамотно сделанной системе можно такую базу слить вообще?

Не путайте СУБД и Java. Это всё-таки разные — ортогональные вещи. Человеческий фактор тупизны тоже не в тему.

[Viewizard]

[оффтопик]
Йоооо.... отшлепать бы вас всех за оверквотинг, аж в глазах рсбит... да вы ж поймете это как сексуальные домогательства...