Language Aside, What I Miss Most for JavaFX Development

After some demos and small things, I've started the development of a small, possibly real world application for JavaFX mobile ("possibly" because, at present time, there's no way to run it but on the JavaFX Mobile Emulator - hoping for announcements at JavaOne). The current stage of the project has been submitted to the JavaFX Coding Challenge (the project is named blueBill Mobile). After the previous experiments, this time I mentally approached the job with the usual attitude that I have when I develop real applications in Java (think of modularization, best practices, process, software factory, etc...) - just with a bit of residual trade-offs since I still have to consolidate my JavaFX skills.

So I'm not commenting - for now - on the language itself, but on the tools involved in the development (mostly NetBeans, but not only). Here are my basic points (the first ones are well known and obvious):

1. Windows needed for Mobile. This is the most trivial and obvious point: at the moment JavaFX is available for Windows and Mac OS X only; but you can use Linux for development with some tweaking. Unfortunately, JavaFX Mobile restricts the choices to Windows alone, which for me hurts a lot. Being in a troubled situation with my laptop (Windows doesn't boot after some maintenance on the disk, and I don't have room on the Mac OS X or Linux partitions for a virtual box), I had to resort to resuming my almost-broke-down previous laptop (fortunately I never get rid of anything!). In the end, most of the work has been done in Mac OS X, not running in JavaFX Mobile of course, and testing/fixing for it with Windows only in the last two days of work.


2. Immature compiler. Maybe I am too oriented in doing weird things, but I often get the JavaFX compiler to crash for an internal error. Of course, getting the error in your source code gets hard in this situation.


3. Immature NetBeans editor support. The autocompletion breaks almost always and the editor gives lots of false errors; you can't format the source and the "fix imports" more often removes needed stuff than adding the missing one. Also the "live preview" feature for graphic components tends to break when you start working with CustomNodes.


4. Can't modularize in sub-projects. I've always been acquainted in designing for maximum decoupling and high modularization - this is even more true since I'm dealing with NetBeans RCP development, where I have literally hundreds of sub-projects, each making a single and simple thing. With all kinds of Java projects, including JME, NetBeans allows to declare dependencies among projects. With JavaFX it is not possible - or, better, it is not always possible. In Mac OS X, with the "Standalone" profile, it works. You just have to declare a "dummy" main class for library projects. In Windows and the "Mobile" profile, it doesn't work. The compiler can't find attributes of classes defined in library projects - the autocompletor suggests to prepend a $ in front of the variable name, but of course the thing doesn't work.


5. No support for JUnit. In spite of talking of it only at this point, I'd say that I could survive some more months without the previous stuff, but NOT with this one. No JUnit means no TDD (or "mostly TDD") and it's a big pain for me. You can work around a bit on this, too bad that NetBeans doesn't give you a specific test folder in JavaFX projects - mixing tests with the paying code is not a good idea. In the end I approached this by putting tests in a separate project (that depends on the main project), but see the previous PITAs about sub-projects.


6. No Continuous Integration. Well, I'm not saying it's impossible, but with all the points given so far, you get that setting up a JavaFX project in Hudson is hard. I've not performed an exhaustive search, but I've never run on a blog post about using Hudson with a JavaFX project.


7. No Code Metrics. As far as I know there is no JavaFX support by Cobertura, Findbugs, CheckStyle. I won't be able to survive much longer without them.

JavaFX Mobile has got its own specific issues, and one is really frustrating: MOBL-272 causes an OutOfMemoryError after you've loaded just a few images (I've seen also other people complaining about this for their contest submission). I can hardly thing of any reasonable mobile application that doesn't make a large use of media - figure it out in case you need to deal with maps, as I do. I'm pretty sure this has been fixed in the upcoming next release.

I do expect big improvements announced at J1 for points 1, 2, 3. I sincerely hope for point 4, but I'm not so sure it has been explicitly addressed; but I presume it's related to a compiler bug, so it could go away. I'm not even sure that point 5 has been addressed, but with all the bugs fixed we could be able to manually set up a JUnit infrastructure with a small effort. So, point 6 could be addressed as well. I have small hopes for point 7 in the medium term... I'd only like to know whether somebody in the tool communities are working on JavaFX support.

In spite of all those pain points, I must say that JavaFX-the-language is so productive that I was able to produce some decent stuff in only ten elapsed days (I started working on the Coding Challenge candidate on May 19), including a re-write of an existing JME full-fledged component for rendering maps. And I'm not out of my learning path yet. Of course I didn't work full time on it, since I've got to work to my paid jobs and live a bit of life in the meantime.

I didn't change my mind about Swing (I still see it as the primary stuff for regular GUIs), but JavaFX attracts me really a lot for what concerns mobile development. It is a great simplification with respect of JME MIDP and could be a significant step for reducing the fragmentation in the JME world. Furthermore, the same mobile stuff also runs as an applet, and this is a plus (blueBill Mobile could be enjoyed on notebooks such as the EEE PC). Of course, you have to redesign the UI for taking advantage of the larger screen, but it's an easy matter of good design.

Of course, my enthusiasm about JavaFX Mobile also largely depends on the adoption rate that we're going to see (in a world where people still sound skeptical about JavaFX itself). In addition to future phones with explicit JavaFX support (so far, only Sony Ericsson endorsed it), according to what Sun said some time ago, with a tool named "JavaFX Mobile Player" you could run JavaFX on a good number of recent phones (including one of mine). This would be a really important point for starting a relevant penetration in the market. Of course, for quite some time you'll have to run a backup and risk mitigation strategies: blueBill Mobile will also have a regular JME MIDP version (most of the code will be borrowed from my other project windRose).