At the beginning of this week, if you were a Java developer for mobile devices, life must have seemed pretty good. The vast majority of worldwide installed mobile operating systems (Android, BlackBerry OS, and Symbian) treated Java as a first-class citizen — but, come the end of the week, and Android has quickly become the only native choice for Java developers going forward.
This week, RIM announced BBX, the company’s next generation of OS that merges BlackBerry OS and QNX. While developers can develop natively on BlackBerry OS in Java, BBX offers no Java solution — developers for BBX will have to use either C/C++ or an HTML 5 package.
The moment that BBX appears, it will relegate Java to the world of legacy and development via third-party environments on the BlackBerry platform.
RIM insists that BlackBerry 7 OS application development will continue, and that there is plenty of money to be made in the environment. That may be true in the same way that COBOL continues and allows developers to generate revenue, but there is hardly the excitement or innovation occurring with COBOL that occurs elsewhere in the software world. The company states that its preferred method of targeting both BBX and BlackBerry OS is via HTML 5, so Java developers will have to find an alternative.
With RIM’s platform moving away from Java, that leaves developers with the choice of Android as a modern OS that uses Java natively — Symbian is out of the equation, as it is the archetype for BlackBerry OS in the legacy world.
It’s not a bad place to be at all; Android is the majority smartphone OS, and doesn’t appear to be abandoning Java anytime soon.
But what are the options for an existing Java BlackBerry developer? If you follow RIM’s plan, then you either have to move up the stack to HTML 5, where RIM expects up to 90 per cent of the application development to occur, or you go down to C++ and mix it up with foreign concepts to Java developers, such as pointers and memory management. Neither of these is particularly attractive to a development house with a significant team of Java developers.
The third way is to stick with Java and use a third-party frameworking environment, which likely comes with its own restrictions, or to develop for Android while still being able to target BlackBerry devices. BBX will come with a runtime for Android applications that is based on Android’s open-source releases, which means that it supports only Android 2.3 at the moment, as Android 3.0 Honeycomb and Android 4.0 Ice Cream Sandwich have yet to have their source code released.
In demonstrations shown at BlackBerry DevCon, the runtime worked surprisingly well — of course, the applications shown were hand-picked, and did not violate any of the runtime restrictions. Developers at the conference were able to repackage their Android apps onsite for BlackBerry, many with no code changes. RIM internally said that it had repackaged Gmail for Android, but was legally not in a position to redistribute it, an action that I expect many programming-fluent BlackBerry users to do to fill the application gaps in RIM’s platform.
So confident is RIM in its Android runtime capabilities that there will be no recognition of whether the BBX native or Android runtime is used to run an application.
Were I to start a new Java mobile application as a BlackBerry developer, I would be highly tempted to ignore the suggested development paths for BBX entirely, and develop for Android with a close eye to avoid BlackBerry’s runtime restrictions. That way, I could still target BBX when it appears, get to keep developing in Java, and have the chance to gain new users and revenue from the largest mobile operating system natively as a bonus.
Language inertia is hard to overcome at the best of times, and I doubt that RIM will be able to sway its loyal Java developers to change tack. As BBX starts to come online, it’s an opportunity for Java BlackBerry developers to finally go cross-platform.
Disclosure: Chris Duckett travelled to BlackBerry DevCon as a guest of RIM