What do I want to see developed for JavaFx?

JavaFx is a decent language for coding a User Interface. The interface for FxBattle would have been a bear to write in Java. Other languages might be easier than JavaFx, but I don't know of any that run on the JVM.

====== Performance Debug Tools ======

When I started work on the FxBattle GUI, I discovered that there was little support for Eclipse (my preferred IDE) so I worked on it using NetBeans. This was fine until I managed to get NetBeans into some strange state where I couldn't really build the project. Not Good. A bit later, I discovered a terrible performance issue in the code.

I spent hours trying to track down the problem. I looked online for 'best practices' for JavaFx. What I found was advise like 'don't use too many bindings', 'make unused components invisible', and others. At JavaOne this year, I went to a talk on performance tricks. They gave similar advise.

The problem with this kind of advise is that they are asking you to hunt through your entire code base and do guess-and-check debugging. You're suppose to find a binding, ask the question 'Is this the problem binding?' Then you're supposed to find some way to implement your logic without bindings and see if it's better.

Imagine debugging performance in an enterprise application like this. Our database updates are taking too long... let's look through all our DB queries and change them one at a time to see if the process gets faster. Of course that's out of the question. Instead we use profiling software to help us find the performance problem.

I did use YourKit to profile FxBattle. It told me that most of the processing was spent redrawing the GUI. This was no surprise. The problem was, YourKit couldn't tell me what code was queuing up the redraws that were taking up the time. So I had to fall back to the guess-and-check debug system. This completely killed my progress. I was guessing that the problem was in the JavaFx core anyway, so I just waited for JavaFx 1.3. When it was released the performance of FxBattle was greatly improved.

====== Build Tools ======

Another reason I was working on FxBattle was to learn about build systems. The build for FxBattle is somewhat complex. Lots of subsystems, some of which are JavaFx, some use Protocol Buffers, some are Java, some are Clojure.

The first build system for FxBattle was Maven. I find I liked it better than I like Ant. It gives you more features in fewer lines of build logic. However, trying to get it to do anything it isn't already good at is really tough. There were no tools to build JavaFx, Clojure, or Protocol Buffers. Getting a sensible build put together was a real bear.

Given that Maven is a very popular build system, why wouldn't there be a plugin to build JavaFx already available? On top of that, I had Java Code which tried to invoke JavaFx code. Doing this required the JavaFx Runtime Jars on the classpath. So I should be able to specify a dependency in my POM that makes those Jars available. Nope, can't do that. The Jars aren't allowed in the Maven Central Repo. Why? Doesn't SUN (now Oracle) want people to develop JavaFx apps? Doing that means we have to be able to access the Jars during our build process.

At JavaOne this year, I decided to try rewriting the build to use a new build technology called Gradle. I'm nearing completion of this task. I really like Gradle.
I was surprised to find that there is already a plugin for Clojure and Protocol Buffers. Great! That makes the build much simpler. Though it did take a while for me to figure out how to hook them all up.

Okay, got the back end compiling, now it's time to compile the front end. Where is the JavaFx plugin for Gradle? There isn't one? There is a lot of hype around JavaFx, but an up-and-coming build system doesn't already have a plugin to compile it?

So, I wrote a plugin for Gradle that compiles JavaFx. It is based on Clojuresque and appears to do the job for my use case. I will probably publish it once I hear back from a few people that there isn't already a tool that does this job.

===== Summary =====

We need to be able to debug JavaFx performance.

We need to be able to build JavaFx in all the popular build systems.

Better Controls, CSS, and other such features aren't useful if we can't do the above.