>Платформа Java представляет собой в некотором смысле экзоядерную операционную среду,Тормозное bloatware оно из себя представляет. Так, называя вещи с точки зрения юзера. У андроида вон даже jit не было сколько лет? То есть, по сути, предлагалось програмить на этаком современном варианте васика со средствами для зажимания сорсов. Тот тоже был интерпретатором, как минимум изначально, в своих 80-ых, только вместо команд виртуальных машин жрал без выгибонов сырцы сразу. Кссно проприетарщиков никак не устраивает, да :)
> где для работы приложений, написанных на высокоуровневом языке программирования
> независимо от архитектуры процессора,
Угу. В теории. На практике - сильно сужается область того что возможно напрограммить, жрется вагон ресурсов и, черт возьми, для целевой платформы кто-то должен спортировать этот рантайм. И почему-то сишные компилеры спортированы на в 100500 раз большее число платформ чем ява рантайм. А чтоб еще и не говняный код генерило - с этим у явы вообще швах. В итоге - я вот могу поставить на своей n900 нативный кодек webm+vp8 уже сейчас. Да, скомпиленый под эту архитектуру и прочая. А на яве слабо? :)
>по-сути, используются нативные вызовы к системно-зависимым, но очень маленьким
>и из-за этого довольно хорошо отлаженныи библиотекам.
Наверное из-за их хорошей отлаженности в сановском JRE постоянно находят секурити баги позволяющие беспределить у юзера в его системе, угу. Мое первое знакомство в JRE началось с того что скачав вебстарт у саней по диалапу я через неделю попал на скачку еще одного такого же куска по все тому же диалапу, потому как в старом нашли кульную дыру "веб-апплет может вылезти из песочницы и делать в вашей системе все что хочет". Во круто - бинари из веба вне песочницы запускать. И, главное, потом таких багов еще 100500 было. А конкретно андроидовая ява которая вон сколько без jit была - это вообще пипец. Давайте, напишите нам кроссплатформенный VP8 кодек на яве. Вместе поржом над его производительностью. Может оно даже сможет декодировать видеоиконку 32х32 пиксела в реальном времени :-)
>Падение одного Java-приложения никак не отражается на стабильности работы других,
>чего нельзя сказать о полностью нативных приложениях.
Открою вам страшную тайну: задача разных аппаратных уровней защиты процессора ("колец" в терминологии x86) и операционной системы - как раз защита ОС от посягательсв на нее программ и программ друг от друга. Если операционка это не осиливает - или ей место в треше за кривой дизайн (времена доса и вин95 - безвозвратно закончились) или руки у админов и/или тех кто дефолты составлял - из неправильного места растут. Нормальная современная операционка с честной изоляцией процессов загибаться от проблем user-mode программ права не имеет. Точка. Исключением являются случаи срача с административного аккаунта - админ имеет право оверрайда механики прав и защит. На то и админ. Только в современных системах по дефолту процессы от административных аккаунтов не работают.
>Уровень качества прикладного программного кода и системного программного кода
>весьма сильно отличается.
Да, только ява - не системный код. Стомеговая хреновина не может быть очень качественной по определению просто. В ней всегда будет 100500 багов. В силу размера и сложности.
>А когда ещё приложения берёт на себя функции исполнения нативного кода,
>то это получается ад защищённого режима DOS и Win 3.1 с кооперативной многозадачностью,
Совсем упоролись? Почитайте как современные оси устроены. Времена доса и 3.11 давно закончились, а в современных системах программы сидят в своих виртуальных адресных пространствах и не могут срать ни другим программам, ни ядру системы. А чуть что не так - проц выдает эксепшн и система пришибает в его обработчике засранца, если засранец сам не обработал свои ляпы. Ну не дадут user-mode проге слазить в чужую память нынче. Вообще. Как максимум - программы с административными правами могут просить об этом операционку системными вызовами. Но далее уже дело ОС отклонить или принять вызовы, в зависимости от наличия прав на операцию у вызывающего. Ну и как ОС порулит памятью, так и будет. И задачи нынче модно переключать не спрашивая их, согласны ли они. Чтобы как раз не зависать в случае сбоев программы. Линух именно преемптивно задачи переключает. А в вин3.x прога должна была сама и явно отдать время остальным, самолично толканув message loop, хахаха. Если в своей проге его не толкнуть - система тут же вставала в позу, прога монополизировала CPU а остальные - сосали. Потому то и кооперативная многозадачность. Вас что, основам архитектуры современных ОС и истории ОС не учили?
>когда программы не были защищены даже друг от друга.
А сейчас - защищены. На дворе XXI век, мля. А линух - не дос.
>Или я не прав, и на ARM-процессорах уже есть защита памяти
>программ (знаю, MMU есть уже в ARM9)?
Защиты программ друг от друга нет разве что в uCLinux для совсем простых и древних армов (раритетные ARM7, которые еще до уже устаревших давно ARM9 были). Там в ARM7 контроллер памяти как правило упрощенный (MPU вместо MMU, позволяющий разные права только на несколько регионов и усе) и MPU в итоге может только отрезать ядро от юзермоды соотв. регионами. Запуск на этом чуде линуха - адский изврат и костыли. Линух подразумевает полноценный MMU, страничную память и все такое. У всех современных армов есть MMU и вполне себе есть деление на кернел и юзер. Собссно, линухи на армах ничем таким не отличаются от линухов на любых "взрослых" процессорах. По управлению памятью и дележу на кернел и юзер - "большие" армы - это вполне "взрослые" процессоры. С эксепшнами, виртуальной памятью и прочим. Более мелкие армы для совсем мелкой эмбеддовки могут иметь упрощенный контроллер памяти, но запуск на них линуха - вообще изврат.
