Android uses the Dalvik VM, which is a register-based VM whereas JVM
is stack-based. Neither the specification nor the source code for
Dalvik are available, but it is clear that the bytecodes are quite
different from Java bytecodes. There is a translation tool from JVM
bytecode (.class files) to Dalvik bytecode (.dex files) but it is a
build-time tool only. JVM bytecodes are never loaded onto an Android
However, the Java programming language is used by the SDK to develop
Android applications. The build pipeline uses a standard Java compiler
to produce .class files and then the Android "dx" tool to produce and
package .dex files. In addition, a subset of the standard JRE
libraries are available, in .dex form, on the runtime (I believe they
have used the class library from Apache Harmony to achieve this while
remaining Apache licensed). Therefore it is possible to compile "most"
standard Java source code to run on Android. The same should be true
of the other languages discussed on this list, except that JVM-
specific optimizations will be useless.
The reason for the custom VM is that Dalvik is optimized to allow
multiple instances of the VM to run simultaneously even in little
memory. Each Android application runs in a separate Linux process.
It's my suspicion that Google are only temporarily leveraging the Java
language in order to gain developer mindshare and make use of existing
tools such as Eclipse JDT, and they may well be planning to launch an
efficient Dalvik-specific language at some point in the future.
As Neil has noted, the Dalvik VM, does not consume JVM class files.
The Dalvik VM is not (yet) documented. However the standard library
does contain java.lang.ClassLoader so it appears possible to
dynamically compile classes and get them loaded (but you need the
Dalvik VM spec, of course).
At the moment it appears that languages which are purely interpreted
could probably run on Dalvik. In future languages which currently
dynamically compile classes may well be able to run on Dalvik (it
depends on how the security system is implemented amongst other
issues). Languages which can be statically compiled to bytecode may
well be able to run on Dalvik now - it depends on their API
dependancies (but reflection seems to be implemented so there's hope).
The general need for good performance is going to limit the
applicability of many highly dynamic languages on this platform, at
My bet for the first useful non Java language on this platform would be Scala.
Warning: I have spent about 45 minutes looking at the platform so the
above may be complete nonsense :)
I've actually written simple apps for my Series 40 (read: old, crufty,
and underpowered) phone in Hecl, so I think even highly dynamic
languages will have no problems on anything that can run this system.
> My bet for the first useful non Java language on this platform would be Scala.
Well, if you consider Hecl useful, it's already running (it's a pure
interpreter, so it was quite simple). I'm just curious about the
potential for more "heavy duty" languages like JRuby, Scala, Jython,
BTW, I don't think Google will come out with their own front-end
language... they use Java for a lot of stuff internally, and so many
people know it...why rock the boat.
That's actually very interesting. I think that the main reason for
that is ahead-of-time optimization, since JIT is expensive and
unpredictable where efficient execution is needed on limited
resources. Dynamic languages won't benefit from this optimization as
much as static ones, for them dynamic analysis is actually more