JavaFX, Android, and the psychic octopus
Surely one of the biggest announcements at JavaOne 2010 was the new roadmap for JavaFX, laying out the journey towards a 2.0 release that will be radically different from what had gone before -- not so much evolution, as total revolution. While the details, when they arrived, contained a fair few surprises, the overall radical nature of the roadmap was not totally unexpected; many had suspected some kind of upheaval was on the cards. Since its inception, JavaFX had struggled to define itself within the Java community, upsetting some and bamboozling others. Even the 2.0 roadmap announcement was met with some confusion on Twitter , although eventually most tweeters seemed to get the message.
It would seem the about-turn is a reflection of a shift in the way Oracle wants Java to approach Rich Internet Applications in future, combined with a reality check regarding the limitations of the technology for API coding. No doubt the love-it-or-hate-it feedback JFX seemed to garner from the Java community also played its part in the decision.
Two points in the JavaFX 2.0 roadmap particularly caught the imagination of the Twittersphere. Firstly, the JavaFX Script language is to be discontinued as an official Oracle project, and secondly, the key language features and API (scene graph, binding, sequences, etc.) are to be re-engineered into regular Java APIs, making them accessible to languages other than JavaFX Script.
I have to say I'm sad to see JavaFX Script get dropped (and not just for the obvious reason), although as an open source compiler this probably won't be the last we see of it. Dropping official support, however, does mean the language won't necessarily benefit from the full time expertise of so many developers skilled in the art of compiler writing. Going forward, for the language to survive it has to attract the attention of not only graphics enthusiasts, but language specialists too.
I doubt there were enough desktop programmers in the Java community to truly appreciate the benefit of a DSL like JavaFX Script (more on this point later), and so faced with a barrage of "why didn't you use Groovy?, why didn't you use Scala?", I guess JavaFX Script's days were numbered.
But in a wider sense the change in direction heralded by the new roadmap has, I think, ramifications far beyond just dropping JavaFX Script and re-purposing the APIs to work with Java. In this blog entry I want to examine why JavaFX 1.x divided so many, and consider how the new 2.0 roadmap fits into the current (and future) landscape of RIAs.
Ten ton gorillas
Since the introduction of the first Enterprise Edition, Java has been a heavily lopsided community. The Standard Edition and Micro Edition have always found themselves starved of heat and light, living as they do in the hard shadow of their Goliath enterprise sibling. The gravity field surrounding EE is so great, it even crushed ME, despite ME’s massive initial market penetration. Treated almost as a curious sideshow attraction by the majority of the Java community, ME's growing pains were never addressed in a timely fashion, and its future never seemed to be a priority. I can't think of any other technology that fell quite so far through events of its own making -- even Netscape had the excuse of anti-competitive practices by a major rival!
Likewise, desktop Java has its own woeful tale of neglect (although, to be honest, other complications also conspired to limit its success). JavaFX was supposed to be a brave attempt to address that, to create something new and future facing, ensuring Java’s place at the top table in the second decade of the 21st century. So, naturally, almost everyone in the Java community treated it with deep suspicion!
The EE guys looked at JavaFX and wondered "how can I build a web site out of that?!" (an understandable reaction, given some of them seem to be blissfully unaware anything exists outside of a web browser). The ME folks wanted to know when it would run on a device they might actually have heard of. And the SE clan were mad as hell that the limited Java desktop bodies at Sun/Oracle were not busying themselves adding to Swing.
Of course, of all of these groups it would be the EE people who would ultimately determine the fate of JavaFX, simply because they dominate the community. Naturally they have a highly myopic view of the way software should be written for the internet, a view that sees the browser at the heart of the user experience (no doubt reinforced by over fifteen years of everything being browser based). To sell the EE folks a technology that looked beyond their browser centric worldview was always going to be tough. Many, after all, languished under the impression that HTML 5 had already been anointed as the platform for the next-gen Rich Internet Applications -- case closed!
In term of building application GUIs, the problem with the web browser is (unlike proper UI/graphics toolkits) it only has one layout paradigm — the flow. Granted, it boasts the mother of all flow layout engines -- not so much "everything but the kitchen sink", more like "everything including the kitchen sink, plus a kitchen sink we robbed from next door when they took that two week vacation!". But there’s no getting away from the fact the browser sees everything as nested blocks of flowing content on a page, much like a desktop publisher; and the page/paragraph model is certainly not the way professional GUIs are created.
With its limited GUI capabilities, stateless protocols, and love of server round-trips, the web browser is an excellent choice for applications centred on a basic label/value form, wrapping a CRUD data model (create/read/update/delete, the record-based philosophy of all popular databases). Once you step away from basic forms and CRUD, however, you find the experience gets progressively less agreeable. The more sophisticated the UI, the greater the challenge to pull it off in HTML. And I say this not as an ignorant onlooker, but as someone who spends their working day coding with browser based visualisation tools like the Exhibit semantic web components from MIT's Simile project.
Many believe HTML 5 will elevate the browser to become a fully fledged RIA technology. They seem to think that, like some cheap televangelist, HTML 5 will magically raise the browser from its seat, invite it to throw away its crutches, and have it doing cartwheels around the room. Undoubtedly HTML 5 adds many useful app-centric features to the browser, but it’s still very immature and I suspect will always be a pain to get working across multiple browsers (the label "write once, debug everywhere" is more true here than anywhere else!) You may have been wowed by the latest IE9 showcase app , but the kind of effects IE9 is (just about) able to produce on a web page are already run of the mill for the purpose-made retained mode graphics engines driving Flash, Silverlight or JavaFX.
Ultimately the promise of HTML 5 and Canvas is that, at some unspecified point in the future, the browser may be able to offer the same kind of UI richness as already enjoyed today by the iPhone, Flash, JavaFX, etc. (Of course, by the time HTML 5 catches up, who knows where iPhone, Flash... will be?)
So will the browser be the future of RIAs? Despite its limitations, the browser has undeniably one major advantage: it is massively popular with end users. Every internet device has a web browser, and every user knows how to use it. More importantly, the web makes it easy to find and share applications: everything lives at the end of a URL. That familiarity has served the browser well, so many naturally assume this domination will extend into the future -- RIAs will be browser based, the web has won, end of story!
But one fateful day in July 2008 changed all that...
July 11th 2008 (so says Wikipedia) was the day the iPhone App Store opened its doors for the first time, and nothing was quite the same thereafter!
Previously Apple CEO, Steve Jobs, had insisted the way to write apps for the company’s iPhone was via the Safari browser -- Jobs was backing very firmly HTML 5 and web standards. (Ironic, given what later transpired.) After pressure from developers, however, Apple released an SDK for native iPhone apps, and in July 2008 the first apps started to arrive. iPhone owners quickly voted with their fingertips, and the App Store became an overnight smash hit. All talk of HTML 5 was abandoned, as the App Store became the undisputed USP (unique selling point) of the iPhone product range. And when it became known some developers were getting rich from their iPhone apps -- seriously rich! -- ever more programmers flooded onto the platform, creating a mini gold rush.
Android arrived, bringing the app experience to non-Apple devices, and it too proved to be a success. This was clearly not just a fluke!
What the App Store and Android Market proved was that the web browser was not the only way users wanted to consume their internet apps. The certainty that the browser, and HTML 5, were the sure-fire victors in the RIA race was challenged; now developers had to decided: which skill would be more in demand in five years time, HTML 5/Canvas or iPhone/Android?
As a web developer it would be all too easy to dismiss the success of the app store model as being localised to smart phones. Sure, phones have apps, but laptops and desktops will always have the browser and HTML, right? But the rise of the tablet has muddied even these waters. Devices like the iPad and Galaxy Tab create bridges between the mobile and desktop space -- if the app store model takes hold on tablets, then how long will it be before the desktop falls for the charms of a store model? Today when you meet with a client to flesh out the requirements for their new online app you ask "which browsers would you like to support?". Tomorrow you may well be asking "do you want iOS, Android, or both?"
Of course the game is still in play, and nobody (except, perhaps, Paul the Psychic Octopus) knows for sure what the end result will be. Personally I will be paying close attention to the tablet space. If tablet users access Facebook and Twitter via a web browser then perhaps HTML 5 will have a future as an application platform. If they instead opt for downloading Facebook or Twitter apps, then those with a heavily web centric skillset had better watch out, as the web could start to revert once more to just a hypertext technology.
(Note: I'm not suggesting either technology will vanish without trace, but history has taught us that when two technologies are in direct competition, sooner or later one starts to dominate.)
Dead parrots (or any they just pining for the fjords?)
So where does all this leave JavaFX?
While the dropping of JavaFX Script and the moving of the JavaFX APIs to Java generated the most chatter, two other points in the 2.0 roadmap are probably more important for the future of the technology. First, JavaFX Mobile is to be shelved in favour of an update to Java ME. Second, the JavaFX graphics APIs are eventually going to be able to target HTML 5.
In light of events post July 2008, this seems like a decidedly odd decision.
JavaFX 1.0 was a technology firmly in the native apps mold. But 2.0 seems to be doing 180 degree about face to re-engineer JavaFX for the HTML 5 crowd. Yes, judging by the roadmap it seems JavaFX 2.0 will still be able to target native apps -- but without credible API support extending onto mobile devices (like smart phones and tablets), how can it possibly fit in with Google's Android or Apple's iOS? Surely this couldn't be yet another example of Enterprise Edition's massive gravitational field, sucking everything within close range towards its web centric worldview, while crushing anything that cannot adapt?
It's true JavaFX in its 1.0 form didn't acquire the traction Sun had wanted. (I'm too much of a fan to admit it failed, so let's just agree to say it wasn't as successful as some had hoped!) The dropping of JavaFX Mobile, and with it the "all the screens of your life" agenda, I'm sure was done for pragmatic reasons. But it leaves JavaFX looking decidedly anemic in a possible future were apps may be expected to run across phones, tablets and desktops. Under 1.x there was still a hope JavaFX might find its way onto Android (once current difficulties had been sorted out), meaning it would span all three form factors. Under 2.0 it looks (assuming I've understood the details right) like we're retreating back to separate and distinct SE and ME platforms, with select JavaFX enhancements being added to each.
On the desktop JavaFX 2.0 will be able to work directly with the native graphics hardware (via the Prism stack) or indirectly via HTML 5. Rather than try to ride both horses at once, I think Oracle should choose whether it wants to back a native model of RIAs (a la Android/iOS), or the web model (a la HTML 5), then decisively engineer JavaFX towards that goal. What I'm particularly concerned about is the effort to port the scene graph APIs onto HTML 5 will consume so much of the JFX team's resources and prove so problematic (write once, debug everywhere) that it will act as a ball and chain to limit innovation and slow down growth.
Ultimately, for me, the 2.0 roadmap threw up more questions than it answered. If JavaFX is no longer to be for all the screens of our life, what is it good for? Is it merely for adding snazzy animations to Swing applications, or is it a replacement for Swing itself? (The answer is apparently "the latter".) If JavaFX is no longer required to run on phones, do we need a new UI? -- couldn't we just add a CSS skinnable PLaF to Swing? Of course the obvious answer is the Swing components don't lend themselves to being manipulated in a scene graph, but how often does one honestly need to spin a progress bar through 360 degrees, or apply a blur effect to a file selector?
With the announcement of the roadmap JavaFX has effectively been plunged back into pre-release beta. The transition from JavaFX 1.3 to 2.0 is far from clear; if I commit to 1.3 now, will I be able to move smoothly over to 2.0 (using the open source JavaFX Script compiler), or will the Java-ized APIs be sufficiently different to the JavaFX originals? Even if the answers to questions like these are favourable, I suspect the roadmap has killed JavaFX dead for the time being (how can anyone commit a major project to any technology destined for serious overhaul in less than 12 months?)
While I recognise the pragmatism behind the roadmap's decisions (even if I don't necessarily agree with all its conclusions) the most frustrating part is JavaFX fanboys (guilty!) are now back to the familiar wait-and-see game, biding our time and twiddling our thumbs before we can start over with the new re-imagined platform.
Although I've never pretended everything in the JavaFX garden was rosy, I have always been (and hope to remain) a JavaFX fan. I sincerely wish the development team all the best as they push forward into the uncharted realms of 2.0, and nothing would give me greater pleasure than to see a healthy JavaFX 2.0 dominating the RIA space, coupled with a strong and vibrant JavaFX Script community. But I have this uneasy feeling that the app store will win out (admittedly, no psychic octopus has yet ruled on the matter), and 2.0 seems to be a move away from that model (or, at the very least, a significant distraction in the form of supporting HTML 5).
That's all I have to say on the matter for now. But I'll leave you with one final thought: given Android doesn't really have a native retained mode graphics stack, and relies upon separate XML files for its declarative UI support, wouldn't it be a bittersweet irony (from Oracle's point of view) if an open sourced JavaFX Script found favour with Android developers, coupled with an Android specific scene graph, to create the kind of rich user interfaces that Chris Oliver originally intended for Java?
Now, does anyone know if Paul the Octopus is contactable on Twitter?. I have a few questions... :)