Skip to main content

JavaFX, Android, and the psychic octopus

Posted by javakiddy on September 24, 2010 at 6:13 AM PDT

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 [1][2][3], 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.

JavaFX Script was an attempt to create a DSL (domain specific language) for user interface coding and animation. For those readers who've never dabbled in the black arts of graphics and animation, let me explain: traditionally the GUI programmer uses a general purpose language (or, at least, a language designed for something other than creating GUIs) with a set of graphics/UI APIs sellotaped crudely onto the side. Unlike Java, or C++, or Groovy, or JavaScript, or [insert your favourite here], JavaFX Script was a purpose made language intended to address directly (and grow with) the needs of the GUI developer. Unfortunately its greatest strength was also its greatest weakness: JavaFX Script was not a great general purpose language, and you need a solid general purpose language to create APIs. So the opening up of JavaFX to Java and other JVM languages was a very positive step. Ideally the JavaFX APIs would be built in Java, leaving the JavaFX Script language free to do what it does best: create great user interfaces.

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!

Red Herrings

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 [1][2], 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...

Clairvoyant octopuses

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... :)

Comments

As far as the dominance of

As far as the dominance of JEE and the unnatural attention given to its perspective, I agree.
The ultimate reason for their focusing on the browser is because this is equivalent (in the minds of certain industry prognosticators, business gurus, and other types who forecast / create the future of technology while possessing only a glancing acquaintance with , you know actual technology) to "cloud" based applications. The idea, er I mean business model, is, we create a dependency on the part of the user for access to data/ information and capabilities which they cannot have on their desktop; make people pay for access, like cable TV or Amazon S2 does There's some legitimate ideas in there. We can't all have a copy of Google's server's info on our local machine. But how many companies are living on VC fumes right now promising their investors that people are going to pony up 20 or 30 dollars a month for their cloud-based application? Where is all this money going to come from to keep these companies running? How many 30 bucks a month bills is the consumer supposed to foot? Answer: not enough to keep the whole "cloud" business model afloat. The idea is, do an end run around the problem of piracy and the computer as a universal copy machine by depriving the end users of the data / application in the first place. It only exists :"in the cloud". Computers will just access CPU cycles or memory or information "on demand" and the front end will be a thin device, coincidentally incapable of holding / running pirated anything.
It's not really the future. Computers are too useful for consumers to give up. We can do too much with them as they are , nevermind going foward, to permit them to shrivel down to a "thin applicance".
Someone who didn't know what hubris meant once said "the best way to predict the future is to invent it". That's what's going on. The future is allegedly all going to be thin appliances accessing (for a fee or for advertising or detailed user profiles) remotely housed data.
Thus the disproportionate emphasis on browser based "solutions" .

You're like one stop shopping

You're like one stop shopping for perspective of what's going on in Java Desktop land. I can't agree with you more and that's usually how it is. Thanks for saving me so much time answering the question -what does all this mean then?


XHTML + CSS is the future of all text, with the caveat that deep CSS inheritance makes rendering very very slow and should be severely limited both by programmer best practice and runtime enforcement.


The reason that XHTML + CSS is the future of all text is it does one small thing well, even though it inappropriately over reaches into the arena of "whole UI layout mechanism", as you explained.


The one "small thing" it does well is: it describes what text should look like.


M$'s .rtf format does this will also, but XHTML is renderable in browsers and .rtf isn't.


Plus, XHTML has hyperlinking which represents a huge leap forward.


This "small thing" is extremely important since the continuation of civilization depends on the worldwide exchanging of texts.


If civilization has an agreed upon format which is equal to the task of laying out lines and paragraphs of text in any given language - including technical and domain specific ones MathML, ChemML etc, ones - then that's a huge achievement that we're not going to wander away from.


Not only do we have that, but we also have a universal HTML renderer called a browser. This is the one thing browsers are actually good for- rendering HTML.


Browsers are good for rendering HTML and following links. What they're not good at is UI. In fact, they're so useless that Flash just completely replaces the browser UI and all it's "capabilities" when it shows you a page. Don't forget that- it's not a the browser showing you a Flash animation, it's the Flash UI completely occupying the browser, you know, like the Germans occupied France.


Browsers should be thought of and used as only XHTML renderers. Their rendering engines and ability to follow links are the only good things about them.


Therefore the final resting place for browsers is WITHIN non-browser-based applications. Those non-browser-based applications, like the apps in the appstore are the future of the web. They have access the web on demand- they're connected-but they're not "in" the browser. Each app is connected to the internet and capable, through its browser component(s), of fetching data and rendering HTML on demand anywhere the app's UI needs HTML rendered.


We have it exactly backwards right now. We're trying to stuff apps into browsers.


What I want is just XHTML rendered over here, over there , in this box, in that control, in that pane so my app can present text where and when it sees fit in the defacto lingua franca of the world - XHTML.


What I really don't want is, as you pointed out, my app trying to conform itself to the browser's layout engine- flow flow and flow some more.


The future of the web is device resident apps rendering XHTML as they see fit, where they see fit and when they see fit within the framework of their own application frameworks and layout capabilities.


The WORA of Java circa 1997-2010 refers to the shielding of the developer from the native platform's details and rendering the developer's application the same on any OS.


The WORA of 2010 onward would be the rendering of Java applications the same on all devices. I get the sense that that's not going to really happen today partly because players don't want Java on their devices (Apple/ Jobs) and partly because Java is not open sourced (but see Google and Oracle's lawsuits for details.. something about the TCK and the JCP etc. etc. ) and partly because the memory / hardware requirements to make it really work strain, for just right now,. the capabilities of the devices.


So what is JavaFX ultimately? It's Java7, right? It runs on all desktops. It's a library with a framework that lets you make "modern" looking applications leveraging all the power of Java and everything already written in Java. The missing piece to the puzzle is a device which runs those apps.


At some point someone is going to think it's to their advantage to create that device. It would be great if Java were open sourced and that device were open sourced because that would create a giant sucking sound of developers rushing to that device and the Java platform.


Until then, we're back to the pre-Java world of fragmented development languages and fragmented platforms.


Give me a tablet device that runs Java and JavaFX and I'll conquer the world.


se/me on handheld devices

Tablets are already capable of running SE, and they'll only get better ... why would they need to run ME? i.e. is removing JavaFX from ME even a real issue for handheld devices? Presumably the devices that are so limited they can only run ME are going to struggle to run JavaFX anyway.

JavaFX acceptance

Two important factors for the acceptance of JavaFX: 1./ Open Office being re-written in JavaFX 2./ Having a first class plugin for IntelliJ IDEA It takes a very long time to compile a large Java/JavaFX project in NetBeans. IntelliJ IDEA just compiles what you've changed. While the first factor might be symbolic, the second is anything but! Larry Ellison promised the first. Is it still going to happen? Is the second in jepody? I hope not.

Java Warehouse

You sound like your angling for some kind of Java Store or maybe a Java Warehouse. Seriously what happened here? (cant get in as Im in the UK) was this made any clearer at JavaOne?

The JavaFX Script-on-Android

The JavaFX Script-on-Android idea has been circulating in the community for a while... let's hope that it really starts now.

The strength of "apps"

I've enjoyed such a blissful browsing experience for so long using AdBlock+... sometimes I forget how websites support themselves! ;-)

Naturally site operators hate this, but the "cat & mouse" game is clearly being won by the ad blockers; auto-updates come out almost immediately after a new trick is developed to get ads back in. In the hight of irony: In order for ad-supported Google to garner any chance at acceptance of their new Chrome browser... they had to support ad blocking plugins!

Generic browsers, formerly a strength, have become a liability for high-value websites. So now you now even see print media adopting the "app" format.

My prognostication: "apps" win for both rich user interfaces and traditional online media.

Mind you, browsers have their place; nobody is going to install an "app" for every site they visit. Websites also get indexed, whilst "apps" don't. However, for big-money or rich-interactive media: news agencies, video, games... the browser is not viable long-term. Conversely, people accept the idea of paying for "apps," yet nearly all attempts at pay-for websites are met with failure.

John

PS Oracle, there is no reason why the "app" approach wouldn't work in the enterprise too!

On JavaFX->HTML5 support

I've heard that too, but just general comments (any link to a clear statement from Oracle?). This item is conspicuously absent from the official Roadmap, certainly not planned for the initial 2.0 release at least.

Well, I suppose they can write a Javascript version of the rendering pipeline that will target either Canvas or WebGL. The latter is probably the best choice in both capabilities and performance. Application code could be cross-compiled into Javascript (just like GWT and RAP) or maybe, just written directly in Javascript if you like that and don't need source compatibility with other profiles.

I don't think the HTML5 support would compromise JavaFX's feature set or evolution. 1.3's new profile mechanism is a great solution - you can run the same code in both desktop and mobile, without suffering NoClassDefFound errors for desktop-specific features; the mobile runtime just ignores the nodes or properties that are not supported in that profile, such as effect nodes. The "web profile" could have similar behavior, including a capability API (Platform / ConditionalFeature) for reusable code that needs to adapt itself to the limitations of some platform, e.g. layout managers that must consider effects.

Yes but...

What you have to remember is targeting the web is not like targeting a single platform, more like targeting three platforms (IE, Gecko and Webkit).  Also, with JavaME and JavaFX Mobile it was largely the responsibility of the handset makers to ensure JFX would run well on their phones -- the relationship is entirely the other way around with web browsers.  Mozilla et al owe Oracle nothing, there's no obligation to prioritise particular enhancements or bug fixes based upon problems the JFX team are having.  If the HTML 5 profile becomes a reality, I can see the team spending a large proportion of its development time supporting it.  (I suppose it could always be open sourced! :)

I agree

Targeting webapps will consume many more resources than just native applications. I for one would love to see Oracle focus on native applications. There are plenty of webapp frameworks. The probability that Oracle would displace the 20+ big players is almost zero. Focus on a fight you can win.

Not unlike JavaFX Mobile

Agree with the profiles comment :-). Like Amy said, the proof will be in what we deliver. BTW, we're hiring ;-)

Thanks--that's been a great

Thanks--that's been a great analysis, and you raise a lot of the points that have bothered me too. I have a few more questions. (1) How is cross-platform video and audio coming along? So much of Flash usage is just playing movies, but last I tried, this was not a walk in the park with FX. (2) Is the timeline realistic? They promise a lot for the 2011 deliverable. (3) If this is to be Swing 2.0, is it going to be a part of Java SE, or another download? If so, how licensed?

Great Post

"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."
Great. I think Oracle played the EE community game. Some things on roadmap were seen on blogs, JavaFX Mix Group, etc..