-
Currently Reading
Android’s Custom Virtual Machine is a Good Thing
Posted on November 22, 2007
Filed Under Software Development |
The “Open Handset Alliance” (referred to as Google for the remainder of this blog entry) has taken on the task of writing their own home-brewed virtual machine, “Dalvik“, to run Java applications on Android. Sun has publicly stated that this will fracture the Java platform [news.com]. There is little doubt that Sun is attempting to remind people of Microsoft’s Visual J++ implementation, which borrowed from Microsoft’s famous “embrace and extend” playbook.
Microsoft added language features like delegates to Java as well as provided J++ direct access to the Win32 API. The outcome of this was near-universal hatred, as well as a lawsuit that cost Microsoft 1.95 billion dollars for failing to adhere to the license that they had signed with Sun, all because they tried to extend a cherished language to suit their own needs.
However, the Android situation is different in a way that benefits developers: The interface for Android application development is, syntactically, Java, and the number of standard Java libraries that you are able to use is intimidating [javax.swing obviously not making it to the party]. There are no extra language extensions. The libraries provided work just as the programmer would expect Java to work. You can even use some old Java code you have lying around. Want to roll your own brand of cryptography into the system? Just add your library to the project and recompile, or update the old libraries that you used to what Android offers.
To the programmer, Dalvik is indistinguishable from Java, because it has the same programming interface of Java. This is important to Google’s success on the platform, because so long as people are happy and developing in Java, they aren’t noticing that what they’re programming doesn’t turn into Java bytecode. So long as Android’s development language looks, feels, and smells like Java, convincing people to develop for your platform is easier. The instant you start to stray or add, people will notice, and people will be angry.
Because Android applications are written in a programming language whose interface just happens to match that of Java, this creates a win-win situation for mobile telephone makers. You have a choice of which virtual machine better suits your needs on your gadget. You choose, you win. Not only that, but if you refactor your code’s core logic well, you will be able to implement your application for both the JVM and Android by simply rewriting the interface.
There has been a fair amount of complaints about Google creating extra problems in mobile Java development, but if we look at the scenarios, the situation will never be worse for developers:
Google and Sun Work Together
Sun puts forth a convincing argument to Google that there is no sense in competing. After all, standards are a great thing, and the whole purpose of the “Open Handset Alliance” is to use open standards. As icing on the cake, Sun will even drop the licensing fees.
This opens the potential of having Google collaboration on the future of Java for mobile devices. New standardized libraries could rise from the dirt where once there was nothing. Google designed Dalvik specifically for performance on mobile platforms, and they would not go quietly on sacrificing any of the speed or memory efficiency that their implementation provides. Undoubtedly, they would like some of their own mobile-specific optimizations rolled into the JVM. Not only does this aide application development without needing to compete with Sun, but also allows them to control even more of the code in your computer.
And there are worse things in the world than having Google tweak the code in our machines.
Sun Backs Down
Sun has given up on having their brand of Java implemented in telephone devices, and they decide to continue developing J2ME the way that they have been since the beginning of time. The mobile standard will still be an option for midrange embedded device developers, and it will still be in existence if the “Open Handset Alliance” is destroyed by throwing the Android into the fiery pit of Mordor from whence it was forged.
In this case, developers of new technologies have a huge support base for creating new devices, as well as a preexisting user interface that is standard across any number of devices. You also don’t need to put any extra effort into application development, because Google has already paid developers 10 million dollars to develop for Android. You can write one application and have it supported by any number of devices created by the Alliance, not to mention that all of the coding for new applications is still done in Java, which is as ubiquitous as a programming language can be.
Remember that Google’s dominance in this market is dependent on tricking developers into thinking that they are actually coding in Java. This future is only bad for Sun, who will have lost part of their market, as well as their headlock on the Java virtual machine market.
Google and Sun Compete
If Google and Sun are unable to come to an agreement, and Sun is unwilling to give up on the virtual machine front, they will suddenly be competing against each other for every new telephony device that decides to use Java as an application platform. Google has already anticipated this endgame and took full advantage of their position. They surprised Sun with the announcement that they created their own virtual machine, and they have also created a competition with big cash prizes in order to stimulate application development. As Netflix and the government already know, there’s no better way to get cheap R+D than by offering a cash prize. Your costs are almost fixed, and all you have to do is wait.
Why will this help developers? Because programmers are fickle beasts. If one system is shown lacking on a particular metric, they will declare that the whole system is godawful and that they would have been much better going with technology X because it solves that particular problem so much more elegantly. They also could have done it better, but there’s no sense reinventing the wheel.
Most programmers I know are strong categorical thinkers, and things need to be in one set or another, ranked against each other, and color-coded or otherwise stored. YMMV.
If one of the mobile platforms is found lacking on some metric, whether it be total libraries implemented, execution times on similar hardware, efficiency of memory allocation, etc, you can guarantee there will be a blogging outrage. Blogs will be written by developers who feel disenfranchised, because their needs weren’t even considered. They will comment on how the implementation failure is unacceptable, and hint at incompetence [whether or not this is the case!]. The more popular social networking or news sites will aggregate these collective thoughts into diluted vitriol. Dvorak will write an article predicting “The end of this platform”, and metabloggers will take up the subject about blogging about the failure of this platform, and what it means for the future of the software industry. By this point, it will be such a well-known fact that this platform has serious defects that the choice for hardware manufacturers entering the market will be clear: don’t write software for this platform!
Sun and Google both have big stakes riding on this, and neither of them can be afforded to be named a loser in the mobile gadget market. Sun will have lost control of a small part of Java, a language they have been creating and fostering for years. This would certainly embolden other companies to follow Google’s example, challenging Sun on their home turf and potentially hurting their licensing revenue. Google will have put their money, creative effort, and brand behind a suboptimal project, bringing a gaggle of companies along for the ride. You can either expect the two projects to start resembling each other, or to posture themselves as the results of different tradeoffs.
As a developer, you can keep on doing what you do best: develop. Let Google and Sun worry about the small stuff.
Popularity: 27% [?]
Comments
4 Responses to “Android’s Custom Virtual Machine is a Good Thing”
Leave a Reply
Note to other readers: Dalvik works on JVM bytecode (.class files) not on Java (.java files)
I have not tested this out myself yet, but the documentation says that’s what it does and all of the examples show the same thing: http://code.google.com/android/reference/othertools.html#dx
The classes that Android uses are all written in Java, but that doesn’t mean you have to limit yourself to that language.
I Don’t think your 100% on the ball here, of course you wont have a shot at finding javax.swing but i’ll bet you _might_ have a shot at javax.microedition.lcdui, but somehow I dont think that’ll be the case if google burns its bridges with sun..
Id put my bets on there being enough differences to make direct cross compilation impossible (the EULA for sun’s products prohibits people from infringing on the sun namespaces.)
There’s a lot more hardware out there running MIDP/CDLC than just phones, & Sun’s JCP uses a lot of different companies that have a vested in the specification to hammer out a stable and usable one. so I think that google would have a uphill battle to gain a large market share..
Although if there were some killer features I might be able to convince myself to use googles platform instead of sun’s.
a GC. & Direct access the the H/W, although that would pose some great risks. There was a good reason why sun didnt permit this in the first place (Lack of portability, Lack of sandboxing, lack of ’security’, ability to gain access to HW & SW stacks that would be dangerous).
but on that note with direct hardware access I would be able to do some _neat_ stuff, (like write a app that can rip data off peoples phones as I walk past, or use other peoples connections to the network to make my calls, or even capture then later ’spoof’ someone’s IMEI & networkID..)
Sorry, but your post sounds quite confusing (to me, at least). You’re saying that there’s not fracture as it happened with Microsoft because “Java, and the number of standard Java libraries that you are able to use is intimidating [javax.swing obviously not making it to the party]. There are no extra language extensions.”
I don’t remember Microsoft added language extensions. They dropped some APIs (e.g. RMI) and changed the AWT to include some custom calls. Google droppe some APIs (e.g. Swing) and added a new bunch of APIs (android.*). To me there’s no difference at all.
Second, you’re saying that Dalvik makes no difference. So now I’m asking: are you sure? For instance, I’m doubtful it is able to support bytecode manipulation à la ASM/CLIB, I mean all that kind of stuff that Spring and Hibernate need. Am I wrong (it could be, I didn’t have the time to study it)? Did somebody try it?
@ Fabrizio:
1) Microsoft added delegates to Java
2) You’re right, I obviously oversimplified the situation to make my point. To switch to Android, a developer has to use exclusively the API that is provided, at the expense of access to the machine level code. The .dex format (Dalvik’s machine code) has been broken, though, so I wouldn’t be surprised if third party tools to convert .class files to .dex files existed.
I feel that the benefit outweighs the good for the developer for two reasons. One, the barrier to making a program for cell phones is now effectively zero. Two, Google will be effectively bound to the Java interface, as programmers are intolerant of big changes.