At last year's JavaOne Chris Oliver gave a presentation on JavaFX in which he discussed how he was interested in programming Java2D not in terms of JComponent paintEvent methods that launch into graphics.drawLine(...) or graphics.drawRect(...) code, but instead by allowing the developer to create an object model representing a Java2D picture. He also wanted to use scripting to describe a figure graph of objects rather than Java code, having seen the success of other scripting languages. Most important, Chris was interested in making this accessible to the kinds of people who like to use professional drawing packages to create artwork so that they could be more engaged with application development without having to throw their designs over the wall to programming teams. In addition, JavaFX would have built into it concepts such as animation, data binding, and a host of other concepts that, although supported in Java, are otherwise difficult or verbose to write.

Ladies and gentleman, the Eagle has landed. Last month the JavaFX SDK Preview was made publicly available at http://javafx.com/. Plugins for developing FX with NetBeans can be downloaded from http://java.sun.com/javafx/ downloads/, which also contains links to Project Nile, a very exciting piece of work that makes plugins available to Adobe Photoshop and Illustrator so graphic designers can easily export their artifacts to FX, something demo'd very nicely by Rob Brewin at this year's JavaOne.

The last year or so must have been an incredibly tough journey, not only for the Sun engineers working on FX, but also for the Swing team who have had the spotlight taken off them for a year or so, as well as the Sun marketing and management team who have had to play the game of getting the timing and technology messages to the right people at the right time.

My opinion of FX is that it is a technology that could really change the way programs are created. Its original name of F3 was an abbreviation for Form over Function, a term in architecture that describes the process of first designing what a building is going to be used for, such as a school, a sports hall, or a fire station, and then building it to be fit for this purpose. A lot of software development, especially user interfaces, works the opposite way. The developer gets a set of pre-defined bricks from a palette and assembles the GUI based on arranging these within totally alien things called layout managers. The designer is forced to follow an incredibly narrow set of rails that the programmer is comfortable with building along. When any deviation is suggested, the cost is large and the developer counters with the argument that the reason everything should be gray on gray on gray with a square button saying "OK" and "Cancel" is because that's what users are familiar with and so forth.

The Holy Grail is to allow the designer to describe the application and its interface the same way an architect designs a building, and for the builders and programmers to just make sure the thing doesn't fall down when it gets windy or too cold in winter. JavaFX has the potential to do this GUI development. For those who bash it, there is probably a certain truth to their diatribe, but I think back to how immature Java was when it was first released and how quickly ideas can go from concept to mainstream development. What we should do as a Java community is to try out the FX SDK, discover its strengths and weaknesses, and try it out on some proof-of-concept projects, giving feedback to the development team on where it is lacking or needs improving, and hopefully help Java to recapture its lost crown of the rich Internet application space.