I originally took a quick look at the original JavaFX when it was first announced. When I heard the concept I thought it sounded interesting to potentially use on the desktop front but on the web front it was a no-no. Perhaps I'm wrong, but I honestly think HTML5 will rule the roost there and JavaFX is really too late. I also really didn't like the scripting language - some people do and I can see it's benefit, but for an application that I'm creating fully it created a bit of unnecessary complexity in my opinion.
Anyway, this was all a few years back now and for a number of reasons, but primarily because it looks a promising technology for an aspect of my PhD, I've been giving it another look. I've wanted to ever since I saw the impressive keynote demo last year, but hadn't had the time to really get into it. For the last few weeks however that's changed and I've been playing away!
Initial impressions, I have to say, are good. It is now of course fully Java, the scripting language has gone. I expected after playing around with it for a while I'd find various bits of the API I didn't like or were missing, had to be done in an awful way, inconsistencies and so on. But that's not the case (at least not so far.) The API is very clean and consistent, much more so than swing, but a lot of the good design elements from swing carry across. A lot of the same design patterns are used and therefore have a similar methodology for events and suchlike; a lot of the panes will be familiar (BorderPane for instance is akin to the old BorderLayout on Swing) and so on. The names of the components do conflict with the old AWT model, as in a button is just called "Button", not "FXButton" or similar, but I like that - as long as you make sure the right things are imported it works well and saves a pointless FX prefix just because an archaic technology once had no prefixes!
While you can of course do what used to be done with swing, creating the normal GUIs, JavaFX is much more flexible. It works as a scene graph where everything is a node that can be attached, edited or detached. This makes a lot of things that were awkward and slow remarkably simple and fast (it's all hardware accelerated) in JavaFX. Even something as simple as moving a circle across the screen previously required dealing with loads of BufferedImages, redrawing everything at a certain point then refreshing it, then implementing double buffering to get rid of the flicker, and even then CPU usage was way higher than it should've been for something trivial. With JavaFX though that's all done for you under the hood in a much nicer way. Want to create an effect on something? Simply call the setEffect() method with a number of built in effects such as blurs, shadows and so on, or create your own. Want to move something around? Simply create a timeline that defines a number of key frames using various properties, then call the play() method on the timeline. No double buffering issues, speed issues, refresh issues, threading issues... when you're used to crowbarring those sorts of things into place it is a very welcome break!
Of course, I mentioned earlier that everything was a node, which is true - this includes the normal GUI components like buttons, not just arbitrary shapes like circles. So if you want to give a button a drop shadow effect, you just call setEffect(new DropShadow()); as you would on any other node. And if you want a button to subtly fade colour in and out, you can implement it easily using a timeline.
The only criticism I have, and this isn't really a criticism of the framework itself, is that because it's so new there's very little material around on it. No books are out until next year, there's only really the official Oracle tutorials (though they are good) and the rest of the time you really have to ask the questions yourself if you want the answers. But like anything along these lines, that does increase with time - and if you do look at the old JavaFX 1 stuff, a lot of the concepts can be transferred across (a lot of the properties have stayed similar for instance just shifted languages.) And it does seem to be rather slow at taking off cross platform - so far there's just a dev preview for Mac and nothing for Linux.
In terms of adoptability (coined word there) it's compatible with swing in that you can mix the two now - so transferring applications across gradually is also an option.
With Java 8 though it should be included as standard hopefully - potentially confining Swing to the legacy zone, which I personally would welcome! It's a nice framework, clearly thought out and very nicely designed. I'm sorely tempted to use it for any new apps I'm writing now, and as it becomes more standard I'm more tempted to port existing applications across.
Anyway, this was all a few years back now and for a number of reasons, but primarily because it looks a promising technology for an aspect of my PhD, I've been giving it another look. I've wanted to ever since I saw the impressive keynote demo last year, but hadn't had the time to really get into it. For the last few weeks however that's changed and I've been playing away!
Initial impressions, I have to say, are good. It is now of course fully Java, the scripting language has gone. I expected after playing around with it for a while I'd find various bits of the API I didn't like or were missing, had to be done in an awful way, inconsistencies and so on. But that's not the case (at least not so far.) The API is very clean and consistent, much more so than swing, but a lot of the good design elements from swing carry across. A lot of the same design patterns are used and therefore have a similar methodology for events and suchlike; a lot of the panes will be familiar (BorderPane for instance is akin to the old BorderLayout on Swing) and so on. The names of the components do conflict with the old AWT model, as in a button is just called "Button", not "FXButton" or similar, but I like that - as long as you make sure the right things are imported it works well and saves a pointless FX prefix just because an archaic technology once had no prefixes!
While you can of course do what used to be done with swing, creating the normal GUIs, JavaFX is much more flexible. It works as a scene graph where everything is a node that can be attached, edited or detached. This makes a lot of things that were awkward and slow remarkably simple and fast (it's all hardware accelerated) in JavaFX. Even something as simple as moving a circle across the screen previously required dealing with loads of BufferedImages, redrawing everything at a certain point then refreshing it, then implementing double buffering to get rid of the flicker, and even then CPU usage was way higher than it should've been for something trivial. With JavaFX though that's all done for you under the hood in a much nicer way. Want to create an effect on something? Simply call the setEffect() method with a number of built in effects such as blurs, shadows and so on, or create your own. Want to move something around? Simply create a timeline that defines a number of key frames using various properties, then call the play() method on the timeline. No double buffering issues, speed issues, refresh issues, threading issues... when you're used to crowbarring those sorts of things into place it is a very welcome break!
Of course, I mentioned earlier that everything was a node, which is true - this includes the normal GUI components like buttons, not just arbitrary shapes like circles. So if you want to give a button a drop shadow effect, you just call setEffect(new DropShadow()); as you would on any other node. And if you want a button to subtly fade colour in and out, you can implement it easily using a timeline.
The only criticism I have, and this isn't really a criticism of the framework itself, is that because it's so new there's very little material around on it. No books are out until next year, there's only really the official Oracle tutorials (though they are good) and the rest of the time you really have to ask the questions yourself if you want the answers. But like anything along these lines, that does increase with time - and if you do look at the old JavaFX 1 stuff, a lot of the concepts can be transferred across (a lot of the properties have stayed similar for instance just shifted languages.) And it does seem to be rather slow at taking off cross platform - so far there's just a dev preview for Mac and nothing for Linux.
In terms of adoptability (coined word there) it's compatible with swing in that you can mix the two now - so transferring applications across gradually is also an option.
With Java 8 though it should be included as standard hopefully - potentially confining Swing to the legacy zone, which I personally would welcome! It's a nice framework, clearly thought out and very nicely designed. I'm sorely tempted to use it for any new apps I'm writing now, and as it becomes more standard I'm more tempted to port existing applications across.
Comments
Post a Comment