JavaFX 2.0 opens new doors: tools!

by Алекс Руис on September 28, 2010

By now it is old news that JavaFX 2.0 will be decoupled from JavaFX Script. JavaFX 2.0 will provide a Java API while JavaFX Script will not be developed any further. My perception, from reading blogs and tweets, is that there have been mixed responses to this news. I personally welcome the change, and the main reason is it will instantly open a new door of opportunity: tooling.

JavaFX Script is a really nice language for creating UIs, no doubt about it. For me, learning a new language was not really a big problem. The main issue I had is the lack of tools available for JavaFX Script, a normal situation that any new language has to deal with. Even though we had pretty good IDE support in NetBeans and Eclipse (thanks to Exadel,) the following are tools, important in the development cycle, that were still missing:

  • Testing Frameworks: Using TestNG or JUnit 4 was cumbersome, since JavaFX Script did not support annotations
  • Maven: even though I tried fill up that gap, it was never as good as the out-of-the-box plugins
  • Static code analysis and metrics: Cobertura, FindBugs, Checkstyle and PMD, just to name a few
  • UI testing tools: (you saw that one coming, didn’t you?) FEST and Jemmy provided some support for testing JavaFX-based UIs but they were not as near good as their Swing-testing counterparts

Of all the tools I mentioned, UI testing tools are the only ones that need to be rewritten. The good news is that having a Java API for JavaFX will make the job of UI testing tool writers a lot easier. We won’t have to work with the bytecode produced by the JavaFX compiler, which was very difficult to understand (I complained blogged many times about it.) Even though we have to start from scratch, we can move forward a lot faster!

Last but not least, alternative languages are another great tool at our disposal. If Java is not your cup of tea, it will be possible to build DSLs on top of the new Java-based API, like Stephen and Jonathan demonstrated at JavaOne.

In conclusion, a positive side effect of having a Java-based API for JavaFX is that it brings back all the power that Java tools have been giving us for years. In my opinion, being able to choose the language(s) to use for writing JavaFX UIs and being able to measure code quality is a huge win.

Update: There are also good news for folks that want to keep using JavaFX Script. Stephen Chin announced that he plans to keep JavaFX Script alive, in the form of Visage. As a side note, I’d like to contribute my JavaFX plugin for Maven :)

(Image taken from m kasahara’ flickr stream under the creative commons license)

{ 2 comments… read them below or add one }

Todd Costella September 28, 2010 at 7:47 am

It always struck me as odd that the FX implementation was so tightly coupled to the language. I’ve only spent maybe 20 hours looking at FX/Script and while it seemed like a good DSL for graphics it still seemed a bit “me too”. With so many excellent JVM languages available now I think the move to exposing the scene graph and other Java/FX goodness makes a ton of sense.

Using languages like Groovy, particularly when coupled with the Griffon framework will make this a powerful addition to the Java Desktop landscape. I’m curious to see what other applications folks can come up with. All in all I for one think it’s a great move. If only a couple of years too late.

Reply

Tbee September 29, 2010 at 2:39 am

Even though Exadel did try very hard, JavaFX support in Eclipse was still buggy and not really suited for multicomponent development. I’m pleased we’re back on Java soon.

Reply

Leave a Comment

{ 2 trackbacks }

Previous post:

Next post: