JavaFX is creating quite a stir these days and a quick trip to Google provides tons of reviews on the good, the bad and the ugly of this new framework. This is my contribution. The difference here is that I’m a beginner who needs to use JavaFX to create a production system quickly. As a result, I’m learning as I go along. This review documents what I’ve experienced so far. It’s not a detailed analysis of the framework, but more a practical review of what to expect if you need to use the framework to develop something useful. I specifically stay away from providing coding examples. This is intended more more people deciding whether or not they should use the framework.
Like the subject says, I’m a JavaFX beginner, so corrections and improvements to this document are most welcome.
Overview
I write Java code, and focus on both JavaSE and JavaEE. The majority of work I do revolves around communications systems and the integration of custom designed embedded platforms (ARM/ATMega etc) with JavaEE based enterprise backends. I don’t like graphics, I have no patience for it, and quite frankly create unattractive user interfaces. I work with the parts of systems that user’s typically never see and avoid graphical work where possible.
My current project contains various multimedia aspects that need to be tightly integrated with an enterprise backend system. And JavaFX is here to save the day … kinda. All tests have been performed with JavaFX 1.2. This is the first – and at the time of writing — the only version of JavaFX I’ve used.
The Good Stuff
Quite simply, JavaFX makes creating graphical applications fun. The declarative syntax takes a little getting used to, but nothing major. After a day or so I found it pleasant to work with for this type of development. My early experience with JavaFX went something like this:
Day 1: Working through the official JavaFX tutorial, by the end of day 1 I’d successfully downloaded and installed the framework, set up my Netbeans 6.5 IDE to handle JavaFX and learned enough to write a simple class and perform non-graphical work like adding numbers together, printing out strings etc.
Day 2: By the end of day 2 I’d created a window with fancy text that used a gradient effect for the background. I’d tied this in with the animation framework to have the text move back and forth on the screen. I’d experimented with the effects like reflection and transparency, drew some shapes on screen and played with things like rotation.
That’s quite a leap for a single day, but none of it is rocket science. JavaFX really makes this type of thing easy to do. By the end of day 2 I was sold on the platform and decided to use it as part of my project. As an added bonus, I soon discovered that with little to no modification, JavaFX applications can also be used as a web application.
And Then I Tried Using The Media Player…
JavaFX comes complete with a media player which doesn’t suck. While the user API is standardised, the underlying media player implementation is different on different operating systems. On the Linux version of JavaFX which I use, the media player is built on GStreamer which, quite frankly just rocks. It took me all of 5 minutes to read through the necessary documentation and have a flash movie playing on screen. By changing a few parameters in the code I was able to resize the movie. And because JavaFX (on Linux) uses whatever GStreamer uses, I could easily play MPEG, and AVI files as well, encoded with a variety of codecs. Swing never rocked as much as this did…
And then I looked at my CPU usage …
JavaFX was eating up 75% to 80% of the CPU time on one of the cores of my dual core machine and playing a fairly low quality clip. This was at a resolution of 640×480. I cut the resolution down to 320×240 and the CPU usage dropped to around 55%, but closer to 60%. Mplayer plays the same clip in fullscreen and uses up maybe 25% of the CPU. The CPU usage often dips below the 20% mark.
I suspect it’s not Gstreamer that’s the problem, but the way the JVM renders movies to screen, since totem is based on Gstreamer and that’s no CPU hog. So while this really is a great start for JavaFX, it does require massive optimizations in this area.
“But you have the power of Java behind you” said Sun …
Playing more with JavaFX, I started looking into using the framework for proper application development and quickly discovered that, even though the tutorials don’t explicitly state so, I can simply instantiate a String object, or use a BufferedInputStream or use any one of the many useful classes Java provides by default. Great, it means I can use my existing Java knowledge and make quick work of this project. Sun Microsystems really were on the right track….
“Ummm … you read the fine print about XML right?”
I like XML for my configuration files, especially now that JAXB is so easy to use. My XML work typically involves the following steps:
-
create a schema in Netbeans
-
create a JAXB binding for the schema in Netbeans
-
move on with life
So step 1 went smoothly with JavaFX. And then the world came crashing down. JavaFX can’t do JAXB. JavaFX can’t even do normal XML processing by default. It has some pain-in-the-ass SAX wannabe parser (javafx.data.pull.PullParser) that’s perfect for not doing anything serious. I’m currently using it to process an XML file and wondering how the hell they managed to make playing a zillion media formats easy, but screw up XML parsing. Just include JAXB by default dammit.
“Here little programmer, jump through this hoop … good programmer … now you can talk to the rest of Java. Well maybe not.”
There’s no proper communications link between Java and JavaFX. I’ve read the articles where you can you interfaces and reflection and such to communicate between the two, but the fact is both of those are workarounds to screw-ups.
I’m referring to the fact that there’s no proper way of launching a JavaFX script from Java and communicate with said script. There’s a ScriptEngineManager interface that can be used for launching the parsing and launching the script, and then … errr … somebody didn’t think that far ahead. There’s no decent means of communication; you can’t instantiate a JavaFX object and use it in Java like you can do with Swing. Oh sure there are ways, but when reflection is the best way to make a simple function call, something has seriously gone wrong.
JavaFX is great, provided JavaFX is in control. JavaFX can use other Java libraries without much difficulty. But not the other way around. A regular Java application can’t, as yet, be in control of a JavaFX script without going to a lot of — what I consider to be — unnecessary effort. This is one huge gaping oversight on Sun’s part.
“Look Ma, I can Animate Stuff …”
Before I continue with more bitching, here’s a definite pro. JavaFX makes animation easy. It’s as simple as saying move something from point A to point B and how long the animation should last. Very nice and intuitive all in all.
With little effort, I’ve moved text, images and drawings around the screen. Want to speed things up? No problem, just tell JavaFX to perform the animation in half the time. Want to slow down? Tell JavaFX to take twice as long. All exceptionally simple to do.
As many people have noted, the animation performance is sluggish and the animations often appear jerky. It’s sad but true. There are numerous ways of improving performance but unfortunately none of them helps too much. A quick list includes:
-
Enable caching on as many objects as you can
-
Reduce your frame rate (which helps with short animations, but makes longer animations look jerky)
-
Reduce the number of “bind” objects
-
Avoid using effects
Google will point you to many articles detailing how performance can be improved but, quite frankly, this is a problem. Apparently the engineers at Sun are looking into improving this considerably in forthcoming releases.
For my part, I found the best way of smoothing out animation is to push up the framerate. This only works to an extent. For my test applications, a framerate of 25fps looked exceptionally jerky. Around 80fps – 100fps looked much smoother, but used up considerably more CPU time. Any higher framerates made no noticeable difference.
Still, forget the days of moving objects manually and computing offsets and worrying about double buffering to create animation. JavaFX simplifies things tremendously.
“You want threading? You can’t handle threading!!!!”
So it was on a bright Monday morning when, after planning out parts of an application in my head all weekend, I decided to implement it by launching a new background thread of execution. And JavaFX bitchslapped me. There’s just no other way of saying it.
JavaFX doesn’t support threading for some reason. There’s probably a good engineering reason for this, but nobody bothered to tell me what that is.
Power of Java my ass!
I created a class that extends Thread. I tried to call Thread.start() but nope, JavaFX wouldn’t let me. So I created a class that implements the Runnable interface and tried to launch that from a Thread object. Sort of the same thing but I thought maybe I’d get away with it. No luck there either. And so I’ve used one of the most retarded concepts I could think of, which, I’m sad to say, actually worked.
I created an ordinary Java class called Bootstrap and in the constructor of the Bootstrap class, I create a thread and launch it. Then, by simply instantiating the Bootstrap class, I have a background thread in JavaFX. I made sure to take a bath afterwards.
That’s the sort of stuff one shouldn’t have to do. Really, WTF?
A main loop, a main loop, my kingdom for a main loop …
My threading escapades arose from the fact that I didn’t have a main loop to work with. There’s probably a way around this, I just don’t know what it is. Basically, I want a Java application with a JavaFX frontend. I just want to get rid of Swing and use JavaFX instead. Sun, sadly has other ideas. Ideally, I want to start an application, launch the user interface and sit in an infinite main loop handling events like data retrieved from a socket, or dispatching data received from the UI to some enterprise backend. I’m not sure how to do something simple like this with JavaFX.
The best idea I’ve managed to come up with (threading aside), is to use the animation framework to trigger a callback handler every once in a while, then have the callback handler — which is implemented as a state machine – handle the necessary events. An overly complex solution to a problem that shouldn’t exist in the first place.
And finally, a word on IDEs
I like Netbeans for for Java development (Eclipse for everything else) and I’m disappointed with the current JavaFX support. Many of the basic features are missing from Netbeans 6.5.x and Netbeans 6.7.x including code formatting, decent auto completion, proper refactoring etc. The IDE really does speed up development though, with a nice panel of commonly used JavaFX components, a preview window and decent debugging support.
Again, unless someone recommends otherwise, I’ll be sticking with Netbeans. They have a long history of creating an IDE that just kicks butt, despite faltering a little along the way.
Conclusion
For all my complaints, I must admit that JavaFX really is a great framework and overall I think the pros outweigh the cons – maybe not in quantity, but certainly quality – especially when using it for graphical applications. I’m still using it. Yes, there are many more problems than I would have anticipated but I expect Sun will address them in time. Many of the issues mentioned above seem to be problems experienced by the JavaFX community in general. It’s only once you move away from the neat guides provided by the tutorials that you get to experience the big cracks in a potentially great system. But that’s the reason I’m sticking with it; I really do think it has the potential to be great.
