Summary
Dalvik is the virtual machine at the heart of Google's newly announced Android mobile platform. While Android programs can be written in Java, Dalvik defines its own binary format. Stefano Mazzocchi comments on what Dalvik means for mobile Java development.
Advertisement
With the release of Google Android SDK, many developers are happily discovering that Android's programming model is based on Java, and that Java IDEs, such as Eclipse, can be used to create Android applications. However, Google usese a special-purpose virtual machine, Dalvik, optimized for embedded execution, and one that has its own binary format (Dalvik Executable), and does not use the Java bytecode format.
In that sense, Dalvik represents a counter-trend to Sun's increasingly visible goal to make the Java VM multilingual. Similarly to Android, the Google Web Toolkit, GWT, allows developers to use familiar Java syntax, but compiles Java source code to JavaScript instead of Java bytecodes.
Every Android application runs in its own process, with its own instance of the Dalvik virtual machine. Dalvik has been written so that a device can run multiple VMs efficiently. The Dalvik VM executes files in the Dalvik Executable (.dex) format which is optimized for minimal memory footprint. The VM is register-based, and runs classes compiled by a Java language compiler that have been transformed into the .dex format by the included "dx" tool.
The Dalvik VM relies on the Linux kernel for underlying functionality such as threading and low-level memory management.
Today Google released the Android code and I took a serious look at its internals... and found the solution for the licensing problem. It's called Dalvik and it's the new name of Sun's worst nightmares.
Dalvik is a virtual machine, just like Java's or .NET's.. but it's Google's own and they're making it open source without having to ask permission [from] anyone...
But Android's programs are written in Java, using Java-oriented IDEs (it also comes with an Eclipse plugin)... it just doesn't compile the java code into java bytecode but (ops, Sun didn't see this one coming) into Dalvik bytecode.
So, Android uses the syntax of the Java platform (the Java "language", if you wish, which is enough to make java programmers feel at home and IDEs to support the editing smoothly) and the Java SE class library but not the Java bytecode or the Java virtual machine to execute it on the phone (and, note, Android's implementation of the Java SE class library is, indeed, Apache Harmony's!)...
The trick is that Google doesn't claim that Android is a Java platform, although it can run some programs written with the Java language and against some derived version of the Java class library...
Not only [does] this allows Google to avoid having to battle thru the JCP for any change to the Java ME "standard" or tolerate Sun's unique ability to veto any JCP change, but gives users a much more 'fresh' and modern class library to play with and built-in hooks to all the hardware features of your phone, including things like OpenGL, bluetooth, USB and all those things, which don't come with the standard Java ME and therefore cannot be taken for granted by the developers.
Google ... not only unlocks development abilities on the mobile phone but also unlocks millions of potential Java mobile programmers from Sun's grip on it.
What do you think of Google's approach to mobile Java development with Dalvik?
So is there any reason why we need the Sun JVM in the general case anymore? Will any old VM capable of running (translated) Java bytecodes plus Apache Harmony do the trick? Will it be possible to develop a non-Sun non-Java VM that's more suited to the needs of Groovy/JRuby/Scala from scratch which can also tap into Java libraries?
> general case anymore? Will any old VM capable of running > (translated) Java bytecodes plus Apache Harmony do the > trick? Will it be possible to develop a non-Sun non-Java
The Java math specification is rather specific/exacting, so code relying on that may not work as intended.