| The Dalvik bytecode is very different from the Java bytecode. The "converter"
you're talking about ("dx") is actually a full compiler, but it just expects as
input Java bytecodes instead of Java source code.
Any "compiler" is just a
really fancy converter that does a lot of transformations between different
representations, optimizations, and things like that. The Dalvik VM stores its
temporary variables in "registers", so the compiler has to decide which
variables to put in which registers, and add extra instructions to handle
situation where it runs out of registers, etc. It makes lots of low-level
decisions that are way too tedious for programmers to do by hand.
Note that
there are a couple of reasons why it makes sense for "dx" to use Java bytecodes
for its input format, instead of source code:
(1) They re-use the
"front-end" of the Javac compiler, which already knows how to parse Java code.
As Sun upgrades the language by adding new features into Javac, they can
piggyback on those improvements (they only have to add the necessary back-end
support to Dalvik, but not to their own compiler front-end, since they didn't
write one). As it happens, Java bytecode for its stack-based VM architecture is
a very reasonable intermediate representation for another compiler to start with
(its not too far from the abstract syntax tree you end up with in a simple
one-pass recursive-descent compiler).
(2) It will work with source languages
other than Java! As long as they can run their code on
a Java VM, their compiled .class files can probably be run through dx and
then used on Android too (unless they require APIs that Android doesn't have).
Even if there was no use-case for this at the time Dalvik was designed, it was a
forward-thinking choice.
[ Reply to This | Parent | # ]
| 
