BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Dalvik, Android's virtual machine, generates significant debate

Dalvik, Android's virtual machine, generates significant debate

This item in japanese

Bookmarks

With the release of Google's Android SDK earlier this week, there was much discussion of the APIs and the expected impact in the mobile space. However, one particular area which generated significant debate in the Java community was the Dalvik virtual machine which is the basis of the Android platform.

One of the first differences which is noted between Dalvik and a standard Java virtual machine (JVM) is that Dalvik is register-based, whereas JVMs are stack-based. There has been speculation that the register-based approach was chosen because it allows for greater ahead-of-time optimization, which is beneficial in constrained environments like mobile phones. A more in-depth analysis of register-based versus stack-based virtual machines concluded that register-based VMs allow for faster execution times at the expense of programs which are larger when compiled.

Another difference between Dalvik and Java is the execution environment - Dalvik is optimized to allow multiple instances of the virtual machine to run at the same time in limited memory, and each Dalvik application runs as a separate Linux process. Neil Bartlett points out that giving each application it's own process allows dynamic installation, activation and deactivation, however he questions why Dalvik would choose that instead of using OSGi to enable this within a single process - Radoslav Gerganov replied that separate process prevent all applications from being closed if the VM crashes. Carl Rosenberger also pointed out that OSGi could also probably be ported to the Android platform, while Jilles van Gurp wondered why Google was choosing to reimplement several components such as inter-process communication.

Java is also no longer the only language which one can target Dalvik with - there has been some success in running Scala on Dalvik, and Hecl has also been ported. There has also been an attempt to get Groovy running, however it has not been as successful to date. Miguel De Icaza, Mono project founder, has also expressed interest in integrating Mono with Dalvik once the Dalvik source code becomes available, and there has been speculation about several ways that this could be achieved including a CIL-to-Dalvik recompiler similar to the Java-to-Dalvik recompiler provided with the Android SDK.

The creation of Dalvik has also raised concerns that the first major fracturing of the Java platform may be in progress - some have related Dalvik to Microsoft's JVM and the lawsuit that Sun filed against Microsoft, wondering if a similar thing might happen with Google, while others have pointed out that Google is not claiming that Dalvik is a Java implementation, whereas Microsoft was. Sun has expressed concern over this potential fracture, and has offered to work with Google to ensure compatibility between Dalvik and the JVM - Google replied that Dalvik was an attempt to solve the existing fragmentation in the Java ME platform, and to provide a platform which had a less restrictive license. Some have even wondered whether this might be a sign of a larger power struggle between Sun and Google over the future of Java. Ian Skerrett saw the creation of Dalvik as a reaction to Sun's attempts to control and protect the revenue stream from Java ME, as well as a reaction to the lack of progress in establishing a governance board for OpenJDK. This caused Dalibor Topic to wonder if Google might follow Sun's path:

The interesting question is, of course, why doesn’t anyone have the courage to ask the same questions of Google, that they ask about OpenJDK? :)

Android is proprietary, despite being marketed as open source. Android has a compatibility pledge, signed and kept behind closed doors. Android has no governance model, nor any indication there will be one. Android has no spec, and the license prohibits alternative implementations, as that’s not a use licensed by Google in the SDK license. Android is completely controlled by Google, and Google reserves the right to kill off competitors applications if they hurt Google financially, etc. It’s only as open as it is in Google’s financial interest to allow openness, by design. Same old proprietary Java wine, in a different bottle.

It’s as if we’re witnessing the rebirth of the JCP, with folks lined up to lend open source community ’street credibility’ to another closed off vendor cartel around a single, proprietary implementation, this time with Google instead of Sun.

Stefano Mazzocchi posted an in-depth analysis of the license issues surrounding Java ME and Dalvik, and concludes that Dalvik is well positioned to make an imapct in the mobile market. Although Google has been careful to avoid several potential points of litigation, Mazzocchi believes that intellectual property lawsuits will be filed by Sun (and possibly by IBM). He also notes that, by operating outside of the JCP, Google is able to modify Android much more rapidly and is able to avoid Sun's ability to veto any JCP change - they can also add interfaces for components such as USB and Bluetooth which are not available in the base Java ME implementation. Finally, by licensing Dalvik's source code under the Apache license, mobile phone carriers are more likely to adopt it since they can use and modify it without paying licensing fees.

Dalvik appears to be causing quite a stir in the Java community - what are your thoughts?

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Not sure how I feel about this.

    by Porter Woodward,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I think it's extremely important to differentiate between Java the language and Java the platform. The language has a specification so I would imagine just about anybody would be free to create a compiler that adheres to the language specification.

    In fact, unless I miss my guess there is at least one major implementation of a Java compiler that does not produce byte code which runs on the JVM. GJC is bundled with Redhat Linux - and iirc it produces native code - compiled and linked to native libraries.

    How is this really different that that?

    The debate over whether their VM is stack or register based is relatively meaningless. Considering the goal of using the Java language (or any higher level language - above the Assembly level) is to insulate you from the underlying architecture of the machine (virtual or otherwise). Interesting from an academic standpoint - but beyond that? Although it might be neat if Java code could be compiled with an indicator as to run-time preference - so that if you fired up a Java application that had been compiled with stack or register based architecture in mind a dual mode JVM could run either more or less optimally.

    In some respects the debate application per process versus OSGi has some merit. I can see either way - but I can also see why it's smart to let the OS handle the processes. I'm guessing the idea is that as a developer you should be able to code your app - and not worry about it taking out anything else; something the OS is pretty good at enforcing. Java has a lot of facilities similar to that - but I'm thinking the OS level facilities have been around just a little bit longer possibly making them a little more robust.

    The way I see it - Google has created a VM - hosted on a Linux base. They happen to have chosen Java (the syntax/language - not platform) as a first class development language for it.

  • mobile, schmobile

    by Patrick Mueller,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Dalvik is optimized to allow multiple instances of the virtual machine to run at the same time in limited memory, and each Dalvik application runs as a separate Linux process.


    I'm thinking that would be useful in server environments as well. And desktop environments as well.

  • Re: mobile, schmobile

    by Frank Carver,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I'm thinking that would be useful in server environments as well. And desktop environments as well.


    That was my first thought. At last there is a light at the end of the Java Commodity Hosting tunnel.

    Up until now, most low-cost hosting companies have refused to offer server-side Java. Giving each user/app a whole JVM is too expensive in resources (particularly RAM), but sharing a JVM allows one malicious or buggy application to bring down all the others. So we are stuck with the likes of PHP.

  • Re: Not sure how I feel about this.

    by Michael Neale,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Android works off bytecode, which is compiled with a "normal" compiler, and then it cross compiles the bytecode itself, so its not really bound to the Java language spec (only the bytecode spec).

  • Re: Not sure how I feel about this.

    by Fabrizio Giudici,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    It's difficult to have an opinion with such a set of contradictory news. Can please somebody clarify (and give references) about Dalibor's point of Android not being open source?

  • Re: Not sure how I feel about this.

    by Fabrizio Giudici,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    ... about DARVIK not being open source...

  • Re: Not sure how I feel about this.

    by Dalibor Topic,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    The license for Google's Android SDK download is not the Apache license, and is in fact not open source at all. You can see Google's license yourself at code.google.com/android/terms.html and compare it with the Apache license at ASF's site. You'll notice significant differences, and I've collected some of the more revolting clauses of Google's proprietary license for the Andriod SDK at robilad.livejournal.com/#entry_22312 .

  • Re: Not sure how I feel about this.

    by Dalibor Topic,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I should also point out that Google intends to keep Android proprietary until late next year, or until the technology is 'established', according to an Android presentation last week in London by Google.

    While Google is of course free to license their own code as it pleases them, using an announcement for an open source stack to sneakily ram down a proprietary SDK with outlandish obligations down unsuspecting developers' throats (you'll notice that the Android SDK download site does not warn users that the SDK code they are downloading is not available under the Apache license contrary to what the press release said it would be) is rather disagreeable, to put it mildly.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT