JavaFX: the “whaou !” factor

Yesterday’s evening was Paris JUG (Java User Group) meeting dedicated to RIA technologies. The first presentation by Francois le Droff (from Adobe) was about Flex and the second one by Simon Ritter (from Sun) was about JavaFX.

Flash / Flex for the frontend, Java / Spring for the backend

First of all, let me state that I have never ever been a huge fan of Flash. From the early days of the web, I’ve always found that “simpler is better” and when I encountered website with flash based animated menu I was always horrified: it was so low, so “in your face”, so not standard… So my impressions may not be objective. But nevertheless I know that some useful and pro applications are made possible thanks to flash.
So basically, Francois started by presenting Flash, Flex (Flex is ActionScript + MXML for GUI building compiled into a swf file) and Air (the VM). Then he became more specific about Flash/Flex and Spring integration on the server. He demonstrated how a flash application sent to a client could communicate with Java/Spring code in the server. This allows to keep existing backend in Java while providing clients with the great experience (well, that’s the marketing terms, not my own thoughts 😉 ) of a flash based app. The thing is that now, Flash and Spring can be even more tightly integrated than before, when the “Spring factory” was used.
The new framework seems to offer synchronizing facilities. When the client is offline, modifies locally some bunch of data, and then is back online, then some conflict detection may be used. Moreover, thanks to the experience of Adobe in this field and the existing tools, the integration of artists work is said to be easy.
But the important problem for me lies with all the plumbing involved. Watching the presentation reminded me of the EJB 2 days where simple things required a lot of code, of configuration and the developer had to maintain many files coherent. It was very error prone. And even more here where 2 different languages are involved ! In the end, I feel like it may be a good technology but that may require a lot of efforts to deal with both the Java code AND the Flash code.

JavaFX, impressive in 2D. But only a toy ?

Regarding JavaFX, I was just curious because I never really took the time to dive into this new Framework/langage. Simon Ritter started with the basics of what JavaFX is. Basically, Java FX is a declaration language in which you describe what you want and how to display it instead of building from scratch your app. So its declarative nature takes it more toward HTML than toward Swing. It is said to be simpler to integrate UIDesigner and graphists work (the one done in Photoshop and Illustrator) but I don’t really see how… Nevertheless, apparently you can export their work from Adobe CS3 and CS4 files directly to JavaFX. And a Designer Tool is said to be ready quite soon (the marketing department did not allow Simon to show it if I remember well. What a shame !). What is sure is that JavaFX really seems a simpler Java2D than a “Swing 2” framework.
– First of all, the notion of ‘scene graph’ is fundamental. The elements are all grouped together with a parent/son relationship
– out of the box, many effects are available (motion blur, lightning shadows), plus transitions (fade, scale, rotate…), animations (timelines, keyframes…). They all allow to customize easily the components of a scene.
– medias can be integrated. Video for example are rendered at worst using a software codec if no hardware is available. And the Mediaview is a part of the scenegraph and treated as all other nodes (effects can be applied and so on…)
All of this reminded me of a 3 month internship I did in the video game studio Cyanide. At the time I worked on the menus (main GUI) of a rugby management game using a custom scripting language. What a shame we did not have JavaFX at that time ! I really think it can allow to create easily very good-looking menus even in videogames.

But the thing is that you still have to CODE your app. And for this, JavaFX makes thing (supposedly) easier by removing (most of the) need for the listener pattern in GUI because it provides the concept of *binding*. You can define that a variable (‘a’) depends on another variable (‘b’). So each time ‘b’ is modified, the new value of ‘a’ is computed again. The binding is optionally lazy.
I was quite disturbed by the lack of object orientation of its syntax though… For example you can write:

var revDays = reverse days

delete 31 from days

insert 5 into days

The summit of the presentation was the demos: Simon did a HUGE performance there, using Netbeans running on Ubuntu. It started with a round clock where the hands of the watch were replaced by concentric circles. With curved text on each circles ! But it was only a matter correctly positioning each character of the String, no magic involved here… Then he demonstrated the demo of a book: each page had a specificity (some writing, a video, a translucent page…) and you could turn each page with the mouse resulting in a realtime animation extremely realistic. It was a bit like this demo, but much more advanced. The crowd really like this one and applauded loud. The last demo was the ‘magical’ one. It was inspired by Johnny Chung Lee’s work with the wiimote. The impressive part was when Simon handed a plastic frame equipped with IR-sensors in front of both a wiimote linked to the laptop (thanks to a Java bluetooth stack) and a videoprojector. A card was displayed by the computer+projector onto the frame, and when Simon moved (or flipped !) the frame, the program moved the image accordingly. In realtime ! Even if its hard to describe it here, believe me: that was amazing and the crowd gave an ovation. It reminded me of the Natal project that Microsoft recently showed at E3, on a lower scale though.
In the end, I think that JavaFX has the opportunity to become something very useful: it can create wonderful good-looking application while staying in the Java World. The advantage of using FX for the front end GUI is the same as using Groovy as a scripting language: it enhances the possibilities while leveraging all the existing code and staying on the well-known VM and Java ecosystem. But Simon did not talk at all about the communication between the fat FX client and the backend server. Whether it involves as much plumbing as Flex does or not, I don’t know. I just hope not because, after all, it’s all “Java” !

What’s the future ?

To conclude we have 2 great technologies. But I think, some questions remain:
It seems we can do more and more extraordinary stuffs in basic Javascript. Why use flash or Java FX ? And what’s their advantage versus Google Gears ?
Flash seems not really SEO compatible (although an agreement has been made with Google to reference flash based app content), and deep linking is not a very trivial task (although Deezer made it, each state of the app has a different URL). I think it’s the same for JavaFX.
Nevertheless, the future looks promising and I can’t wait to see JavaFX become mainstream !

minor edit on 2009-07-14: added links + corrected typos

Advertisements

Share this:

Like this:

Related

Post navigation

2 thoughts on “JavaFX: the “whaou !” factor”

Josesays:

Biggest problems with JavaFX in the browser are the following:

. Takes ages to load. A simple app can be several megabytes big(!)
. You get a balloon in the system tray (Windows) saying that Java is running. Imagine if all the plugins would do this…
. You get a huge scary warning dialog that u need to accept before seeing the applet

I can imagine that most users actually clicks on cancel when they get this security dialog, why should I trust this unknown domain wanting to run something that could harm my computer?

. Applets performance is also pretty bad on Macs, with repainting issues when you scroll the page containing an applet
. Not everybody has Java 1.6 installed

How can JavaFX possibly compete with HTML 5 and Flash with these issues?

I personally haven’t looked at the “official” flex integration. Though I have used blazeds on a real project where we even needed to add the springfactory manually and then indeed you need to make sure that the name in the xml matches the spring bean’s name, etc … indeed making it error prone.

I’m more of a graniteds man myself and over there these these you just turn scanning on, annotate your @Service also with @RemoteDestination and you are done. No xml file to edit, no config file ever changes to add/remove/refactor a service, you can call this ejb3 style? I ‘don’t know, but I like it 🙂

Furthermore I also think that flex has/is going through the same thing as java during the earlier days (struts vs cairngorm) but in the end I really like flex to build my UI because it’s simple. Simple to do databinding, to create custom components, to get the layout you want it to. And hey, I don’t like doing this UI stuff any more than the next “real” programmer, but if I get the choice I will pick the one that is least painfull and over the quickest (same criteria as picking a dentist btw)