I have mentioned before in this blog that I develop apps for the BlackBerry as a hobby. For all my apps so far, I used RIM's BlackBerry Java SDK, which has been their the "official" way to develop apps. I just learned that by next year all my apps will be obsolete. I am not exactly overjoyed. Here are my thoughts.
The big developer's conference for BlackBerry developers is RIM's BlackBerry DevCon, of which the Americas edition just concluded. The spotlight seemed to be on the upcoming BBX OS, built on QNX, that will power the future phones that will succeed the current BB 7 platform next year. We've always known that the current Java platform will be replaced, but we had been told that the new platform will be able to run existing Java apps. Unfortunately, this is not the case. Instead of a more gradual transition where "legacy" apps will continue to run, the BBX platform will accommodate absolutely no BlackBerry Java apps.
There is a cynical way of looking at this. You could say that RIM is throwing their loyal Java developer community under the bus, courting instead the larger community of HTML5, Adobe Air/Flash and Android developers, whose apps will run on BBX. But dropping Java compatibility is not in RIM's self-interest, since a lot of existing business and enterprise apps are still written in Java. Why lose compatibility with thousands of existing apps if you can help it? My suspicion is that RIM can't really help it.
Inside the BlackBerry OS
I admit I'm being presumptuous here. I have no insider knowledge about the BlackBerry OS and internals. Heck, I don't even know if the JVM has a JIT. What I am presuming here is based on how a BB device feels from a user's and developer's perspective.
We know that the BlackBerry uses Sun's J2ME software: it's in the phone's acknowledgements page. My first impression is that the JVM is really a multitasking VM: all "applications" run in the same VM. This explains why small apps start so fast on even a modest early-model BlackBerry: there is no overhead from starting up a new VM for every app. Back when phones had modest CPUs and little memory, you don't want to spin up a new JVM for every process. We don't know exactly what version of the software runs in today's BlackBerries, but we have Sun's 2005 paper describing their CLDC Hotspot Implementation J2ME VM's ability to multitask midlets on ARM devices.
This also explains what RIM calls "Super Apps". A while back, RIM emphasized highly integrated and efficient apps that hooked into the system, which they called Super Apps. The BB OS is particularly suited for that: you have extensive APIs to register your own Java object as a callback for RIM's system apps. For example, the phone app could call your object when a call comes in. The inter-process communication (IPC) facilities are also quite extensive. For example, you can plug in a global event listener that picks up events broadcast from any other app in the system. You can stuff objects in the RuntimeStore: this is essentially shared memory at the Java object level, where different applications can modify and read the object as if it was in each app's local memory space. The phone's own "operating system" -- apps that manage telephony, networking, messaging, the address book etc -- are all implemented in Java and run as peers (though privileged) alongside your own apps. In a sense, your apps don't just run on the BB OS, they run in the OS, becoming part of it. What will happen, though, when there is nothing left in the OS?
A bridge to nowhere
The BlackBerry Playbook's Tablet OS, built on QNX, is the precursor to the upcoming BBX OS. We know that RIM is starting anew, building system code that does not use a J2ME runtime. There is a multitude of runtimes: apps run as native POSIX C/C++, run under Adobe's Air/Flash runtime, execute as HTML5 apps on the WebKit web runtime or in the Android player. The system BBOS Java apps, with their extensive integration APIs, are gone. If RIM were to provide a legacy BBOS runtime, what would be in it? To provide the full BlackBerry API, you might have to basically run the entire OS. But this would be a hollow shell: the crucial system services such as telephony and messaging are no longer being handled there, so those system integration hooks would be useless. The IPC facilities? With apps balkanized into a multitude of runtimes in QNX, a pure Java-based IPC facility would be like shouting in an empty cave: there is nobody to talk to.
The other issue is that booting the OS takes an awful amount of time. I hate starting the BlackBerry OS simulator to test my apps: it's gosh-awful slow even on a modern PC. But that is essentially what you would have to do to run a legacy BlackBerry Java app in QNX. I believe RIM decided that it would be too much work to connect the BB OS APIs to the new system software, and that the user experience of running a Java app under BB OS emulation would be horrendous. The RIM's developer blog states that "We concluded that the BlackBerry Java experience on the BlackBerry PlayBook platform would ultimately not satisfy us, our development community, or our customers as the platform continues to evolve."
This situation should not be surprising for any ecosystem that is entirely dependent on a vendor. We need to deal with the fact that the platform can unilaterally change. Microsoft developers are only too familiar with the constant platform churn. Even now, there is a realization that Silverlight is being thrown under the bus, like BB Java, in favor of HTML5. I think the situation is not too bad.
Personally, I think RIM botched the communication of their Java (non)strategy. They made a difficult decision for what they hope is in their best interest. That interest may not always align with third party developers, but I think we would all benefit from RIM's success.
- DevCon update: BB-Java is dead, no java support for QNX (forum post by developer breaking the news)
- Developer Roadmap: BlackBerry BBX and the BlackBerry Java SDK (RIM's official development blog announcement) .
- Sun's 2005 CLDC HI Whitepaper