Can RIM's Playbook sustain an Android Parallel Universe?

According to a recent video posted on various BlackBerry fan sites, there has been "confirmation" that the RIM PlayBook will be compatible with Google's Android.

According to a recent video posted on various BlackBerry fan sites, there has been "confirmation" from one of RIM's developers that the PlayBook will in fact use a "Dalvik" VM to provide Android application compatibility on the QNX operating system.

Dammit Jim, I'm a technology writer, not a theoretical physicist. This is starting to get way too parallel universe for me.

A couple of weeks ago I postulated on HOW exactly Reseach in Motion might be able to make the PlayBook compatible with Android. It was a "What if" type of scenario. It now appears that it's likely no longer a "What if" or a "How" but a "When" and "Can".

Also Read: RIM's PlayBook: Is it an Android FrankenBerry?

In a video that was posted originally on, an unnamed RIM developer at a booth at the Mobile World Congress 2011 show in Barcelona states that "... we also support Android Apps, when we release the Dalvik engine on top of QNX" in what appears to be German-accented English spoken by a non-native speaker.

Assuming that this information is true, then what RIM has in fact done is opened up a wormhole into a completely new Android universe. Like the one in the classic Star Trek "Mirror, Mirror" episode, but where Spock has a beard.

The reason why RIM's Android compatibility would exist in a parallel or alternate universe is that it would actually be a different development target for Android developers. Not only would they have to test against Google's Android SDK for specific Android releases such as Gingerbread and Honeycomb, but they would have to test compatibility against the Dalvik JVM running on the BlackBerry PlayBook simulator, which runs as a VMWare virtual machine.

As if testing application compatibility against a completely new flavor of Dalvik wasn't a headache enough, developers are also probably going to have to re-submit their apps to RIM's own BlackBerry App World, because it is highly unlikely that Google is going to allow the PlayBook to run Android Market. It also doesn't make SENSE for the PlayBook to use Android Market, because RIM would want to monetize its own app store as opposed to using Google's.

This is the same exact type of strategy that Amazon is pursuing with the "stealth" Android app store that the company is creating, but as of yet, we don't know what sort of device that new store is being targeted for. I've suggested that it may be for a yet-to-be-released Kindle Android Tablet, but so far, no details have emerged from the online retailer.

On the x86 platform, developing a Java app on one platform and moving it to another is supposed to be painless, particularly if you are using say, Sun's J2SE VM on a Windows PC and you want to run it on Solaris, AIX or Linux. In theory, the Java bytecode for that application is supposed to work exactly the same on all platforms if the VM is coming from the same vendor. That's what the whole beauty of the Java platform was supposed to be about in the first place. The raison de etre, so to speak.

However, the reality of Java is very different. Even between Linux and Solaris on x86, where the platforms have a lot of commonality, Sun's own JVM behaves differently on the two OSes (and also on both Solaris architectures for x86 and SPARC) even though it passes all the Java certification tests. Behavioral differences also occur between dot releases of Sun's Java VM on the same platform.

This gets more interesting when you observe how apps behave on the certified JVMs between different vendors, such as when you run that code on OpenJDK or IBM's J9 used on Websphere on AIX, Linux and Z/OS, HP's implementation for HPUX, or on Unisys's special JVM they use for very large memory systems on their ES7000. Or even on OpenJDK for the Mac.

When it comes to compatibility of application code across different types of JVMs from the various vendors, things can get pretty esoteric.

While in most cases you just copy bytecode over and it just "works", sometimes you do find enterprise J2EE/J2SE apps that need to be tweaked for specific platform differences. And while it might take only a few hours to debug the issue and make the changes needed, it's still not 100 percent "write once, run anywhere".

There's another issue at hand here, and it's that Google isn't Sun/Oracle and Dalvik isn't Java. It's not certified as Java, the bytecode isn't Java compatible, and there's this little lawsuit thing that Google is currently engaged in with Oracle to further complicate matters.

The legalities are out of scope for this particular piece. I suspect that if the PlayBook is in fact using a variant of Dalvik, either running natively on QNX or via some binary emulation layer, then RIM has probably negotiated something with Oracle to indemnify themselves and their enterprise customers which will be using Android apps on their device. If they haven't, well... that's room for another post.

So if we expect that when "pure" Java acts differently between different platforms from different vendors, then we can probably expect that RIM's Dalvik-esque VM is also going to behave differently.

Also Read: Blackberry's Android? (ZDNet Networking)

Assuming RIM is going to be able to get developers to re-validate their apps on their VM, and submit their apps to the RIM App World, there's also the issue if Google's Dalvik is going to stay compatible with RIM's going forward.

I don't see Google as this evil organization that would incorporate code in the future in Dalvik that would inherently break applications that ran on the PlayBook -- and at the end of the day, Dalvik is Apache-licensed and Open Source, so RIM will always have full access to the code.

However, as long as RIM is maintaining a "variant" that is not being developed in cooperation with Google, in a "Parallel Universe" (Dalvik ITSELF exists in a "Mirror, Mirror" of Sun's Java) then there is always the chance that RIM will purposely or inadvertently inject variation or code forking to optimize for their own platform, complicating matters for developers.

And Android NDK apps? As I said in my other article, that's an entirely different ball of wax.

Has your head start to spin yet? Mine surely has. I need to remember not to spike my coffee with Romulan Ale in the morning. Talk Back and Let Me Know.


You have been successfully signed up. To sign up for more newsletters or to manage your account, visit the Newsletter Subscription Center.
Subscription failed.
See All