JavaFX Review

I had high hopes for JavaFX as I started reading about it.  At first glance it shares many of the same goals I have: better designer/developer workflow, more declarative applications with better object initialization and data binding.  JavaFX uses the Java runtime for efficiency and doesn’t suffer some of the major performance problems of Groovy and JRuby.  The designers invented enough new syntax here that it will not be as easy to learn and in particular as easy to adopt by Java programmers as I would like.  There are a few key aesthetic changes from Java and a few cases where weird new syntax is used to save a few characters of what would otherwise be more readable code for a new programmer.  A Java programmer would find it awkward to switch back and forth given its javascript roots.  But after reading the documentation and looking at the samples it still felt workable.  Clearly these decisions were made for script programmers and I agree they are an extremely important constituency in IT and under served by Java today.

But as I dug into the implementation I found one deal breaker for me.  Though they can use and extend Java classes fairly well, JavaFX classes cannot really be used back in Java.  They are not JavaBeans and don’t expose fields in a way Java code could access them.  I think it is very important for client/server applications to be able to share code.  That is one big advantage of Java over Flex.  But it does not seem possible to build a domain model in JavaFX and share it between the client and server code.  You could build the domain model in Java and then wrap it in JavaFX but now the domain model itself is inaccessible to the JavaFX programmers and cannot use the declarative features.  How can we get robust/round-trip workflows from different types of developers with this partitioning?  The JavaFX programmers would be waiting for the Java programmers to make some change and could not maintain the complete design when it is finished.  In their prototypes, they’d use data binding and other features that would need to be recoded by the Java programmers.

Maybe they can fix this but right now I don’t need another incomplete wrapper language.  JavaFX may be a decent way for script programmers to get the benefits of the Java runtime but it won’t empower the type of real synergy we need between the different skill sets that build and maintain software.

There are also a few less than optimal implementation details under the hood.  I don’t particularly like how properties are implemented.  They uses primitive fields in some cases but eventually container objects get allocated for each property which needs data binding.  There is a hybrid mode where fields in the object are defined for both the container and the primitive.  The get/set methods lazily init the binding and use that once it has been initialized.  I didn’t see manual controls to enable binding like you do in Flex so I assume they detect binding expressions and enable the feature or not at compile time.  This might work well in practice if you have all of the source and compile times are not too long.

Though bindings in JavaFX may fire a little faster than Flex once things are initialized, my reading of the code tells me there will be a higher memory footprint and more init time cost.  I prefer the simplicity of the Flex approach – I could at least understand how that one worked by reading the code quickly.

In general in JavaFX, there was more code generated than needed to be in there including an extra class for each class which uses data binding.  Complex property initialization semantics also bloat the code just a bit.

JavaFX may well be a good solution for some folks but I’m not banking on it to jump out of its niche, particularly given that it appears Java applets are still suffering from some basic problems.  For example, my experience with the JavaFX samples on my Mac was disappointing.  I encountered some minor install problems and had to redo it a few times.  When I did get things working, the demos flashed as I scrolled the browser window which looked bad and init time did not feel quick and smooth.  These are probably things you can address but if the demos look bad, I guess it is still hard to optimize your applets and remove visual glitches?

I am impressed by http://www.visualthesaurus.com which is also a Java applet.  This is based on thinkmap (formerly plumb tree design) who are early applet pioneers with some custom infrastructure.  So maybe Java on the client can be done right, Sun just hasn’t figured out how to do it yet?  In any case, my advice is to take a wait and see on JavaFX.  Once Oracle has ported over open office, maybe it will have improved 🙂