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."
Going forward
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.
For one thing, we have a choice of platforms: native code, Adobe Flash/Air, HTML5 or Android. The Adobe and HTML5 platforms is theoretically completely portable: target this platform, and your code is theoretically free to roam to other devices, or even the desktop. I think that for many Java applications, the HTML5 platform in the form of WebWorks is the appropriate substitute. You can develop and deploy WebWorks code right now for current Playbooks and BlackBerry phones, and it will work in BBX. JavaScript runtimes have really improved lately, and with today's JIT compilers WebWorks application performance should be more than adequate. And with WebGL, you can even build GPU-accelerated 3D games in JavaScript.
Some developers have expressed a desire for RIM to provide converters to help convert Java code. I don't think this is practical. While Java-to-C or Java-to-JavaScript converters are available, the reality is that BlackBerry Java apps use a very extensive API specific to BB OS that simply won't be there on BBX. The WebWorks BlackBerry-specific API is nowhere as extensive. The BB UI API resembles Swing: nothing like the HTML/CSS UI model. An automated converter wouldn't know what to do with such API calls.
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.
Related links
- 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
Pretty well all Java servers use a single JVM to run multiple apps. Nothing new in that.
ReplyDeleteJ2ME memory is limited of course, and that could be a factor. Except that RIM isn't even going to add J2SE to BBX.
Despite the fact there already is a J2SE for legacy QNX you won't find it on BBX. Why?
The reason RIM is dropping Java is about licensing.
Oracle want revenue from Java, and they're not prepared to extend RIM's preferential licensing arrangement negotiated with Sun.
If RIM pays Oracle what they want they will be at an even bigger competitive disadvantage to Android. (Android pays nothing - RIM pays a license fee for J2ME).
And if Google loses and Android devices attract Oracle license fees, RIM is just one more Android platform (sort of).
There's no reason at all RIM's thousands of Java and C developers couldn't have replicated the BBOS API's on BBX. It's just software. They've managed to do just that for much of the Android API without too much difficulty.
Otherwise I'd agree with you that the strategy has been poorly communicated. I imagine because if you tell developers Java is dead on BBX, then consumers might just stop buying BlackBerry apps - or worse for RIM - BlackBerry devices.
Creating a conversion process - however kludgy - for Java code would have provided RIM with a way of giving the impression *everyone* was being loved while implementing their Java exit strategy.
Thanks for your comments.
ReplyDeleteIn fact, the notion of an MVM is pretty much limited to J2ME. Server-side JVMs do run multithreaded, but that is not the same as multiprocessing. Threads are not isolated: as a server-side Java developer, I have suffered constantly through class sharing conflicts, class loader games, permgen memory leaks and all such fun. J2EE "apps" are basically separate threads running in the same process, with all the potential conflict that implies. The MVM is something different. If you open your application list in OS 6 and newer, you can see that it lists CPU usage, memory consumption etc for each app separately. Processes can be started and shut down separately, cleanly. That is only a dream in standard Java.
As far as licensing goes, I don't see any evidence at all. There is no evidence that Oracle is playing hardball with the only smartphone company still using Java. There is no evidence that any renegotiation is even taking place.
I have already pointed out the difficulties of BBOS compatibility. It's not the same thing, because it is more than just replicating the APIs. Application Java object needs to cross API boundaries, to integrate with functioning system Java code on the other side. BBOS apps integrate deeply with system and other apps in ways that Android apps don't. The implementation on the other side of the API boundary needs to execute that Java code. You probably need to run BBOS itself to get compatibility. You know how slow BBOS boots up. RIM probably came to the conclusion that it was not possible to get reasonable app compatibility and/or performance with the time they have to get BBX out the door.
Really nice blog.I like this blog.thanks for share good blog.
ReplyDeleteRegards,Brus from blackberry development
"The reason RIM is dropping Java is about licensing."
ReplyDeleteI read that in many places. But can somebody explain to me how this works? Wikipedia claims Java ME has been released under the GNU GPL years ago. What exactly would RIM have to license from Oracle except for Java ME?
Great article. Thanks for such brilliant tips. I like whole article but “Never settle for one idea” is very good tip.
ReplyDelete