По сабжу:
Ответ очевиден ИМХО. Потому что для кросс-платформенных приложений - это по сути самый удобный универсальный подход, обеспечивающий необходимую абстракцию от оборудования и ОС для работы одного и того же программного кода. При этом интерпретатор(виртуальная машина) выступает в качестве такой буферной прослойки. Она состоит, условно говоря, из 2 частей - 1) единая и независящая от платформы исполнительная среда, обрабатывающая и интерпретирующая пользовательский код; 2) машиннозависимая прослойка, обеспечивающая стыковку исполнительной среды с той или иной платформой(ОС).

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

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

Разумеется, интерпретируемый код выполняется несколько медленнее, чем на живом камне, но тут нет никакого разбазаривания ресурсов. Да и на современном железе это малоощутимо! Я вот перешел на Java после C++ и не могу сказать, что не замечаю принципиальные тормоза жавных модулей по сравнению с сишными аналогами. Я, конечно, бенчмарков не делал)), но субъективно - разница если и есть, то крайне незначительная.
Здесь в принципе можно опять вернуться к дискуссии на тему кривых рук - наверняка одна и та же алгоритмическая задача, реализованная профессионалом на Java почти наверняка будет намного шустрее аляповатого кода неопытного студента, написанного в виде автономного исп.модуля.

PS
очепяточка: в пред.посту фразу "и не могу сказать, что не замечаю", следует читать как "и могу сказать, что не замечаю".
сорри, народ, пальцы к концу дня затекли)))

Fixin
...
Это понятно, но ведь есть QT, демонстрирующий совершенно другой подход - работу не на всех ОС, а на основных. Почему его начинание осталось единственным и больше никем не поддержанным?

Э-э, вообще-то ОС много есть на свете и я не знаю ни одной виртуальной машины, которая бы работала на всех ОС, они все работают на основных ОС - Винда и семейка Unix'овых. Может кто знает, народ, есть такие?

Fixin
Почему нельзя написать компилятор явы?
...


Потому что это уже не будет Java. Вам компиляторов что ли не хватает, чудак человек?)))
Мы толкуем про кросс-платформенность или где? Любой компилятор(в классическом смысле этого слова) - это привязка к той или иной платформе

Naf Сравнение Qt и Java
С уважением, Naf

Явно заказная хуета. Где бенчмарки? Где реальные сравнительные характеристики?
Одно блабла, высосанное из пальца

Fixin,
"...что не позволяют сделать компилятор JAVA?"

Читайте все посты внимательнее. Ещё раз.
Именно благодаря тому, что в основе архитектуры Java - виртуальная машина, её приложения кроссплатформенные. Компилятор - это другой подход, от которого создатели Java - изначально сознательно отказались именно для достижения кроссплатформенности жавных приложений.
Если Вам так легче, можете считать, что Java - такой особый компилятор)), доля истины тут есть, ибо можно сказать, что байт-код компилируется.

Gluk (Kazan)
Ну конечно :)
а на чем будут писать виртуальные машины ?

На виртуальных машинах, разумеется))
Это из серии - а на чем первые компиляторы писали?

XDiaBLo
...
Я так понимаю на Жаве и НЕТ в основном для корпоративного пользования пишут...

Если честно, не всегда удобно для готового продукта прилагать увесистый аппендикс в виде JVM или фреймворка. Конечно автономные C++ продукты в этом плане смотрятся получше ИМХО.
Насчет корпоративного использования - соглашусь. Java, например поддерживается некоторыми очень нехилыми вендорами. Достаточно про Oracle снова упомянуть, в софт которого Java теснейшим образом интегрирована. За C# тоже нехилая структура маячит, хотя я лично насчет будущего сишарпа менее оптимистичен, чем по поводу жабы