JavaFX SDK Preview - first impressions

The SDK is currently available for Windows and OS X/Intel. So my Powerbook is not supported and Safari applets are not happening until Apple developers get off their collective asses and enable Java 1.6 as the default Applet runtime on Safari. Sure, Java 1.5 might run JavaFX eventually, but it will be severely hindered by this limitation since the latest 1.6 release is a lot better than the older ones. There are also 32bit versus 64bit issues on OS X as well. Making this transition even harder.

All the example code is wrapped as Netbeans projects. I'm not a big fan of Netbeans. I have two versions of Netbeans installed on my Vista system and none can install JavaFX. One is too old and the other is too new. Maybe I'm a dumbass or something, but starting a simple JavaFX application seems to require me to downgrade my current IDE. And running the javafx.exe file just produces the same information as the Java executable. Might be a path problem. So I'm skipping the whole JavaFX runtime and checking out the designer tools in this preview.

Project Nile
The Photoshop JavaFX exporter divides a PSD into its individual visual subcomponents. You also get a JavaFX data file (*.fxd) and a JavaFX UiStub defined as standard JavaFX source code (*.fx). So some random text in a PSD file will create a background image, a flattened transparent version of the text, an FXD file and an FX file. The idea is to separate the assets from the core logic. And it seems to work just fine.

The SVG to JavaFX graphics converter
I created an Illustator file, wrote “Teppefall” in it and then expanded the text into a collection of vector paths. Then added a rectangle underneath to act as a background. The exporter doesn't give you a warning if the JavaFX filename is missing its FX suffix, so you might waste 8 seconds trying to figure out why pressing Convert results in no action. Entering a package name in the exporter will also cause an error message to appear in the Graphics Viewer, which you can't read without maximizing the error dialog. There is a strange Graphics Viewer bug causing the scroll pane to cut off most of the text. The tool is a bit rough, but it seems to do the job in this simple test.

The JavaFX Graphics Viewer
This tool opens a file dialog on start and then exits if you press Escape. A graphics viewer that assumes that I'm going to open only one file at a time is completely disconnected with the reality of design and development. User interface people work iteratively and test out hundreds of versions throughout a single day. Also, the graphics viewer doesn't seem to support drag and drop or opening any other files after the first file. There is also an issue with large background images causing the viewer to scroll even when the PSD's width is set to be much smaller. I assume the viewer is responding to the width of the PSD image layer, rather than the PSD source file. Data exported from Photoshop and Illustrator worked as promised in both test cases.

Media support
It's kind of shocking that there's no audio or video example code in this SDK. I've pointed out before that this is sort of important if Sun wants to be.. say.. taken seriously. There is an API called javax.scene.media which might contain some interesting bits, but I've not been able to test it yet. Sun tells us that we'll be able to use native media API's, but the more interesting aspect is the multi platform media support. Write once, test everywhere gets old fast and we developer guys would like to know what reality we'll be living in. The native API access layer might kick ass, but you can't build Qik, YouTube or Vimeo in it.

JavaFX is starting to look like Ecmascript.
Millions of people understand some form of Javascript and Actionscript, but Sun thinks yet another language is key to the success of JavaFX as a platform. To me, JavaFX looks more and more like Ecmascript 2.0 every single day. Maybe that's the sleep deprivation talking, but JavaFX seems to be less wild in the syntax department. So they have changed one or two things there. I read somewhere that they changed the STONEAGE_NOT <> into a C_NOT !=, so who knows what other things have been normalized. Ocaml is super powerful, but has the mind share of a bad Abba cover band. Maybe Sun didn't want to go in that direction.

Deployment
I can't find any JavaFX tools for deployment other than Netbeans. Adobe has four or five such tools for Dreamweaver, Flash, Flex, Thermo (wild guess) and the various SDK console tools. If Netbeans is going to be the only deployment tool, then a lot of people will be ignoring JavaFX. Sun should build a simple deployment tool for those people who don't use Netbeans.

It's still too early to draw any conclusions. To me it feels like Sun has two people doing UI work, when in reality they need three people per visual tool, two people per console tool and a shitload of people writing media API's. If they starve the project from the start, then this will become the next Java Media Framework. I'm kind of puzzled by the existence of this old media framework and no video capture API's in JavaFX, when we already know that Sun wrote something like that way back in the old days. Hopefully Sun is going for quality rather than buzzwords and quantity this time. There is no point in a capture API that feels like 1999 all over again.

The early Adobe AIR SDK runtime was way more impressive. But Adobe screwed that up by breaking compatibility three times over. The Adobe AIR SDK launch was a huge success, but many people doesn't know this because all they see is Adobe error dialogs. So Sun's timid approach might have some merit to it.