It’s Time To Get Excited About JavaFX
Sometimes, perception is, to all intents and purposes, reality. For many, the perception has been that Java is a monumental disaster on the desktop. To such people, graphical Java software is synonymous with ugly, buggy, slow and generally all-round crappy desktop software. Naturally, those people don’t want Java software anywhere near their computers. They genuinely believe it’s massively inferior to other technology; and that the sooner it goes away, the better. That’s their perception… and so it’s also their reality.
Some people, though, know different. Some people know that Java software has the power to be truly compelling; to amaze and delight people. I’m one of those people. How do I know Java is so powerful? Simple. From personal experience. My teams of fabulous developers, and I, have been developing compelling, graphical Java applications for over a decade.
- I’ve demo’ed graphical Java software to financial analysts in the City of London, who’ve voted my presentations their favorites among company presentations
- I’ve demo’ed graphical Java software to top-tier venture capitalists who told me I’d just given the most impressive software demo they’ve ever seen
- I’ve demo’ed graphical Java software to audiences of over a thousand people who, as one, have gasped in amazement when I got to the really cool part of the demo
- I’ve had CIOs come to me, after company-wide demo’s of graphical Java software, and say that for the first time ever, they had employees demanding their company gets a piece of software, and asking why all their software isn’t like that
- I’ve demo’ed graphical Java software to Nobel Laureates who’ve turned to their colleagues and said that the software is far ahead of any software they’ve ever seen
None of those people knew they were looking at Java software. They were just looking at pieces software with the most amazing, compelling graphical user interfaces. Could we have written that software in languages other than Java? Of course… but not easily. The truth is – Java is probably the most powerful language for developing great software with compelling graphical user interfaces.
So why is it that many people’s experiences with Java have been so different? There are a few reasons. Partly, it’s because, to get the best out of graphical Java , you need to be somewhat of a “rock star” software developer. Those are few and far between. So the Java desktop applications that many people get exposed to look terrible and amateurish. Partly it’s because applets in the browser worked so badly it gave Java a bad name, despite the fact that applets are a different technology to desktop applications. And partly it’s because, until recently, most mobile phones have had limited functionality, so Java applications for mobile phones looked like desktop applications from circa 1983.
All of which brings me to JavaFX. JavaFX is (I hope!) almost ready for a Version 1.0 release. The idea behind JavaFX is to unleash the power of Java, not just to rock star developers, but to all developers and designers. For rock star Java Swing developers, though, JavaFX is going to make your life easier – it will let you add polish to your apps in days, that with Swing might have taken you months. And, more than that, it will extend the idea cross-platform rich GUI development from the cross-desktop development, as it is now with Swing, to “cross-screen” development – from your TV, to your mobile phone, to your desktop.
On day one of Version 1.0, JavaFX won’t be without its problems. I suspect the tool support won’t be there at all – so all the coding will have to be done by hand (how I’d love to have my expectations blown away and be proved wrong on that one though!). JavaFX will run only on the desktop, not yet on mobile (that’s probably six months away). It will be truly usable inside a web browser only on Windows – and there will be no JavaFX applets for Mac OS X at all just yet, unfortunately (Apple needs to release a Java 6 plug-in for browsers in Mac OS X for that to happen).
While it won’t be without its problems, then, there’s going to lots in JavaFX version 1.0 that will be of interest. Just for a second, imagine the possibilities. What could you do with Java, if the powerful things you do today with Swing were suddenly made 10X easier and 10X faster to implement? What could you do, if you put your fantastic apps inside the browser as applets that don’t take an age to start up? What could you do with hardware accelerated 3-D graphics inside the browser? Or applets that can be turned into desktop applications with a simple drag and drop operation? Or streaming video, compressed with a world-class codec? If you’re a rock star Java developer, I think it’s time to dust off that early adopter hat, and get excited about JavaFX…
Rex Guo wrote:
Very well-said!
I think it is safe to say that other than Cocoa/OSX, every other UI framework requires significant expertise to make one’s app look good. Even plain HTML looks terrible without at least some CSS. The same goes for the tons of amateur OpenGL demos/applications out there.
The people (companies included) who figure out how to work with designers and provide the tools to them are the ones with any chance of creating a good-looking app, and here is where Adobe is the undisputed leader: their bread-and-butter business is selling creative tools.
Like you, I’ve also managed to show people apps that I’ve created and they did not realise/believe it was written in Java. It is possible, and not hard at all. Except too few people are trying it in order to create the critical mass required. Catch-22.
Posted 08 Nov 2008 at 7:17 am ¶
Mr X wrote:
I’m interested – been following since it was F3 – hopefully they have now really addressed the problem that put me off then – it was too slow ( being interpreted among other things ).
The key things for me ( apart from working on a Mac – I’m typing this on one ) is how well it integrates with existing code first – for example if want to write a new front end to an existing app I don’t want to rewrite the domain objects or network/database code, and if I want to write part of an app with it how well I can integrate it with Swing.
Posted 09 Nov 2008 at 4:36 pm ¶
simon wrote:
To answer your questions, at least qualitatively:
- It is now compiled to Java byte code. So JavaFX apps run under the JVM. So performance is orders of magnitude better than when it was interpreted.
- It has been designed to integrate with existing Java classes, including functionality for integrating Swing code. So you can wrap an existing app in JavaFX.
- It will, I think, be supported for desktop apps on Mac OS X for version 1.0 (at least, partially). It needs Apple’s Java 6 implementation, though, so that means no applets, because there is no Java 6 plug-in on the Mac. I understand that Sun and Apple are actively working on a “Java 6 update 10″ release – whether that includes a new plug-in, though, I haven’t been able to determine… and I have no info at all on the time-scale.
As to how *well* JavaFX 1.0 works in terms of all the above, we’ll have to wait and see. Lots has apparently changed since the preview release…
Posted 09 Nov 2008 at 6:11 pm ¶
Mr X wrote:
Exactly – it has to work *well* – they look to be doing the right thing – keeping the features down to make sure those that work, work well – we will see.
Also there are two aspects – using the libraries directly – for example like using scenegraph
http://www.nobel-joergensen.com/roller/java/entry/pie_chart_revisited
and using JavaFX.
One of the main concerns I have about JavaFX, and this is something that I’ve experienced with other scenegraph systems, is how configurable is the human/user interface interaction – if you want to do something innovative you often need complete control over how the mouse and keyboard events are managed and don’t want to be fighting the inbuilt model.
Roll on version 1.0 so we can find out ( sorry guys I don’t have the time and luxury of being able to play with pre-releases ).
To all the doom sayers about the Java on the client side – I do agree with a recent Joshy response to a doom a gloom thread – client side java have never been in better shape – update 10 benefits Swing apps and is not just for JavaFX – better fonts on windows being very noticeable.
Posted 10 Nov 2008 at 10:49 am ¶
simon wrote:
I agree. A while back, Joshy asked for suggestions for demo JavaFX apps. One of the requests I made was:
Build a JavaFX GUI that embeds a custom Java Swing class that:
o extends a Swing JPanel
o has custom painting
o has custom event handlers for dealing with mouse/keyboard events, and drag and drop events
This would show a couple of useful things:
o How to embed a custom legacy Java Swing component in a shiny new JavaFX GUI
o How to make sure all keyboard and mouse events end up being consumed by the right part of the GUI.
So, hopefully there will be a demo app along those lines when JavaFX 1.0 is released. My thinking was: if it turns out the final FX scenegraph model doesn’t make it easy to get at low-level events, at least you know how to get around any such issues by using Swing.
To be honest, I’m not too concerned about the “coding” side of things. I’m pretty sure they’ll do a good job over time, even if it’s not perfect in 1.0.
I am a little concerned about deployment issues, though. The question that concerns me most is: is it going to work well enough so that end-users don’t have endless problems with JavaFX applets not working properly? For me, that’s the thing that could really kill the return of Java as a RIA platform.
We’ll have to wait for Version 1.0 to see about this. What I can say is: when the preview SDK was released, I built a toy app that worked great on my system. People asked for the source code, and when they tried it on their systems, quite a few people found the app didn’t work. Now, to be fair, mine was a hard test. The toy app was playing video using a native codec; and that is notoriously difficult area because native video codec support is seriously screwed up in Windows. It doesn’t work properly at the level of the hardware/OS platform, so there’s zero chance it’s going to work properly in apps built on top of that.
Still, there are potentially similar gotchas in areas like hardware accelerated graphics. It’s going to be a total nightmare if developers can’t reproduce problems that end-users experience.
Posted 10 Nov 2008 at 12:43 pm ¶
Mr X wrote:
Not sure they can fix code issues over time – they will want to maintain backwards compatibility – wrong design decisions now could be permanent
On the deployment – absolutely – though I don’t care about applet deployment – I’m more interested in the reverse – JWebPane in my apps.
Posted 10 Nov 2008 at 6:18 pm ¶
simon wrote:
Almost all code design issues can be fixed over time. That’s one of the reason for having the concept of deprecating APIs. If JavaFX gets good traction among developers, it’s almost inconceivable that that platform wouldn’t evolve and improve over time.
Re: JWebPane. Yes, a lot of people are going to be interested in that. I actually think a lot of people will be interested in applets too; the new Java plug-in allows for some powerful applet-browser dom interaction.
BTW, when I wrote about potential “problems JavaFX applets working properly,” I should have written, “applets and applications – many of the causes of such problems would, of course, be the exactly the same for both.”
Posted 10 Nov 2008 at 6:33 pm ¶
Mr X wrote:
> Almost all code design issues can be fixed over > time. That’s one of the reason for having the
> concept of deprecating APIs. If JavaFX gets
> good traction among developers, it’s almost
> inconceivable that that platform wouldn’t evolve > and improve over time.
Tell that to users of swing components like JTable – for example see
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4709394
Ok it’s fixed – but by default the *behaviour* remains what most people who consider wrong and the way to fix it is to the following
table.putClientProperty(”terminateEditOnFocusLost”, Boolean.TRUE);
Which is both non-obvious and as far am I am aware hasn’t made it into the JTable javadocs even now.
I have often wondered why Sun didn’t do a new swing package with these niggling things fix – just like they have done with nio – keep backwards compatibility but allow to evolve – one reason might be it’s potentially harder to make those two packages play together.
Anyway back to the point – with input behaviour on widgets – it’s not really part of the API – you use it *implicitly* – it’s part of the behaviour without you having to call any methods ( that could be deprecated ) this is why it’s so important to get it right and why it’s so important to allow the developer, if they so wish, to completely rip out the default behaviour and write their own, rather than trying to fight the existing behaviour with events etc being swallowed or grabbed.
Posted 11 Nov 2008 at 4:06 pm ¶
simon wrote:
Hmmmm… not completely sure about how this works in JavaFX. As far as I can tell, you seem to have the power to:
- extract a lot of the information you might need from events e.g. get the screen x,y co-ords, while also getting the scene-graph x,y from mouse events etc.
- define yourself how events are propagated (or swallowed) across nodes i.e. by blocking events from being propagated, or allowing events to be propagated
Now, that seems to me to really offer quite a lot of flexibility. But until I try writing some complex apps (which I’m not going to do until version 1.) I’m just not sure how often people with be fighting with the system.
I’m not sure you can rip the low-level behaviour out, though, and define your own functionality. For example, take the concept of a filled vs unfilled node (e.g. a shape of some kind). Here, the way I understand it (and I could easily be wrong – I’m no expert on JavaFX!!) – is that if you click in the middle of an unfilled node, no mouse event is generated. That is, to register a click, you have to click on the edge of the shape. Whereas, if the node is filled, you can click inside the node i.e. on the filled part, and you will register a click. I can see that might be not what a developer may want; but I can also see that in this case, there may be simple workarounds.
Posted 11 Nov 2008 at 7:45 pm ¶
Mr X wrote:
To completely do your own behaviour you’d want to be able to get all the events for the top level frame/component – or any component/node below – before anything else – and if you choose – to be able to stop them propagating – and have nice utility methods for working out which node they are over, local and global x,y coords.
Posted 12 Nov 2008 at 1:09 pm ¶
simon wrote:
As I say, you do seem to have all of that for every node of the scene graph (with the kinds of caveat I mentioned). Whether it’s as nice as it could be, I don’t yet know.
When JavaFX 1.0 comes out, one of the first things I’m think I’m going to try is the new 3-D stuff (assuming that hasn’t been cut). I know from previous experience with (early versions of) the Java 3D scenegraph, that wasn’t the case; so I’m intrigued to see if JavaFX is better.
Posted 12 Nov 2008 at 3:21 pm ¶
simon wrote:
Just heard that the 3-D stuff *has* been cut from the 1.0 release. They didn’t want to do a “half-ass” implementation, so are waiting until it’s done properly (hopefully it will be a reasonably fast-follow from the 1.0 release). I think that’s a good sign; and the implementation seems like it might be quite cool. That is, it’s looks like it might not be a separate 3-D scene-graph (which is what I had been expecting) – instead, as I understand it, there will be a single scene-graph, where you can mix 2-D with 3-D. Sounds potentially very powerful…
Posted 14 Nov 2008 at 12:56 am ¶
javanut wrote:
I’m excited about javaFX – can’t wait till I become a rock star
Posted 25 Feb 2009 at 2:26 pm ¶