JavaFX will probably have a good future but at the moment you have to be very careful when using it. Having worked on a project in JavaFX we have seen a number of issues, one of which is a show-stopper. These comments are for JavaFX 1.2.3. We hope the new release will work better.
Suggestions
When writing JavaFX, treat it as alpha quality. In particular, do small changes/additions to your code and compile regularly to make sure it works and doesn't crash.
Also do regular memory checks to see if it is leaking memory. We did a memory leak test after an early prototype and didn't notice any issues. But they seemed to have crept in with further development. It's been a long time since I've used a system with memory leak issues, I've become to trusting.Don't assume anything will work, in particular bind and bind with inverse. It takes a while to learn when these will and won't work. Sometimes the compiler will suggest new code to get these to work, sometimes you will have to work it out yourself.
Memory Leaks
Unfortunately the biggest issue is the memory leaks you can get from JavaFX. They seem to be related to bind with inverse type relationships.
The following is a link to a writeup from someone who has investigated JavaFX memory leaks.
They seem a bit arbitrary as to how you can get it; so regular testing after short changes/enhancing is the best way to deal with this issue.
The problem is that you use bind with inverse to update an object's fields, but bind with inverse is limited in how it can be used and you really need to create a new GUI screen for each different object you update.
In our case, we leak 4Meg every time we view a new item. On a small laptop, it doesn't take long before the system crashes.
Slow
JavaFX is significantly slow when doing a GUI. This isn't a show-stopper but it is an issue. It should get faster over time, so it is a concern.
Memory Usage
JavaFX uses a reasonable amount of memory, but tolerable unless you have a memory-constrained system.
JVM and Compiler Crashes
It isn't normal to see the JVM crash, but that can happen a lot more when running JavaFX code.
The JavaFX compiler crashing is more annoying. The problem is that you will not know what code has caused the compiler to crash. So incremental changes to code and building regularly is the only way you will pick up the offending code and try to determine what is causing the compiler crash.
Dependency On Third Party Libraries
Any changes to the JavaFX compiler is likely to break existing code; or at least require a recompile form source. In our case, JFXtras. Unfortunately, with the memory leak problem we really need to test against JavaFX 1.3 to see if they have fixed the problem. But our dependencies on JFXtras means we cannot move forwards until they fix their code to compile with JavaFX 1.3. It has been a fortnight and they still haven't released a working version. So if you are waiting on new features/fixes from JavaFX core then it may be a month or more before any 3rd party libraries are updated to work again. An important consideration if you have a deadline to meet.
