Трансляция С++-кода для Java-машины

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

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

nestedvm:

NestedVM provides binary translation for Java Bytecode. This is done by having GCC compile to a MIPS binary which is then translated to a Java class file. Hence any application written in C, C++, Fortran, or any other language supported by GCC can be run in 100% pure Java with no source changes.

GCC-Bridge:

GCC-Bridge is a C, C++ and Fortran to Java bytecode compiler. GCC-Bridge uses GCC as a front end to generate Gimple, and then compile Gimple to a Java class file.

Набор библиотек и инструментов для LLVM для компиляции C в JVM bytecode:

The C to JVM bytecode compilation provided by LLJVM involves several steps. Source code is first compiled to LLVM intermediate representation (IR) by a frontend such as llvm-gcc or clang. LLVM IR is then translated to Jasmin assembly code, linked against other Java classes, and then assembled to JVM bytecode.

Давайте по порядку:

Есть-ли сейчас технологии, где С++-код транслируется не в нативный код для конкретной платформы, а в код для Java-машины?

Такие технологии есть, но только в виде некоего research'а в глубочайшем бета, а продуктиве нет таких технологий.

По моим понятиям Java-код сейчас транслируется в некий промежуточный код для абстрактной Java-машины. На разных платформах есть JIT-транслятор, который при запуске этого кода переводит его в нативный код для данной платформы и запускает. Или я не прав?

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

Вроде бы чего проще. Взять транслятор GCC, оставить синтаксический анализатор а вместо кодогенератора под платформу x86 написать кодогенератор под Java-машину. Неужели еще никто не сделал такой гибрид?

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

Как распространяются Java-программы? Распространяются ли Java-программы в исходных кодах, или Java-программы распространяются в кодах для Java-машины?

Java программы распространяются в виде объектных кодов .class собранных в архивы .jar/ear/war/zip

Для Android обычно упаковываются в архивы APK, которые содержат байткод инструкции транслированные в виртуальную машину Android (она не совпадает с байкодами JVM)

Update

По VM в Android. Dalvik и ее более новая инкарнация ART - отличаются от Sun JVM тем, что Android машинка имеет регистрориентированную архитектуру в отличие от сановской которая имеет стекориентированную архитектуру, что влечет за собой экономию оперативной памяти актуальной для телефонов/смартфонов.

Dalvik начиная с версии 2.2 имеет JIT, которые компилируется в нативные коды в момент первого запуска, в ART используется ее аналог которые называется AOT (Ahead-Of-Time) который компилирует в нативные коды уже в момент установки.

Как чисто нахватавшийся по верхам теоретик... :)

1. Не слышал. Теоретически, конечно, возможно, но есть масса нюансов - одна только сборка мусора чего стоит - которые будут приводить к достаточно извращенному коду на Java.

UPD1. Не совсем. Байт-код выполняется в режиме интерпретации, по ходу выполнения анализируется, и "горячий" код компилируется в машинный - эдакое сочетание обоих вариантов.

UPD2. Опять же - не слышал. Наверное, можно, но ведь пишут не все, что можно, а что востребовано :) Кстати, там своя четкая спецификация байт-кода, весьма специфичная, так что это совсем не такая простая задача: байт-код - это далеко не ассемблер...

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

"По-моему, так" (с) Пух"

Если хочется под мобилки да и на C с крестами, Ваш путь должен лежать к Qt for mobile Я правда сам не пробовал, но Qt зарекомендовавший себя тул, и думаю там все в порядке. Из плюсов - Вы не ограничены только Android.