Hot on the heels of Flash Builder 4 and Flex SDK 4, the much anticipated update to JavaFX is now with us. And WOW, this is just what I was hoping for and more.

OK, the top must-haves are now here:

• More skin-able and CSS style-able controls
• More layout classes

Without these, creating any real-world JavaFX app is just too darn cumbersome.
These additions should make it much much quicker and easier to create JavaFX apps.

A big change/addition I wasn’t expecting is the addition of some charting controls, including Area, Bar, Bubble, Line, Pie, Scatter, and X/Y. We seem to be doing more and more charting in applications at the moment so these will probably come in handy.

Another big addition is that of a load of effects classes. These will hopefully add some nice polish to our apps.

There are many changes in this release, more details of which can be found:
http://javafx.com/docs/articles/javafx1-2.jsp
http://java.sun.com/developer/technicalArticles/javafx/v1_2_newlayouts/

We will now be able to start creating some useful apps with JavaFX so expect more posts very soon!

Following on from my last post, here I have now added a JavaFX port!

Download the latest zip which has actionscript 3, C/C++ and now also JavaFX version of the super NSNotificationCenter.

Well we have spent some time now playing with and investigating JavaFX.
I wont go over some of the big positives I recently discussed but instead will focus on one particular topic – GUI components (or simply referred to as ‘components’ for the rest of this post).

Well here is the problem with JavaFX version 1 release and components – that is the lack thereof.

What is there then?
Well, there are some (certainly not all) wrapped Swing controls – these are the  components in the javafx.ext.swing package, then there is the JavaFX native javafx.scene.controls.TextBox and finally a couple of layout classes in javafx.scene.layout.
But this is nowhere near what I would call complete and a long way off what Sun are intending regarding a component set for JavaFX.

The problem seems to be we are stuck somewhere between using Swing components (which are wrapped in JavaFX classes to achieve such niceties as data binding) and using native JavaFX components which are intended to be nicely skin-able.

There are a couple of issues with the Swing based controls: 1) they are not style-able/skin-able and 2) they will apparently not be available on the mobile platform.

The issues with the native JavaFX controls is simple… they only have one so far!
These native controls will be great and provide the all important skin/style-ability.

So where does this leave us?
I for one am eagerly awaiting Sun to provide a full set of JavaFX native components. When this happens, I  don’t really see the benefit of making use of Swing based components. In fact it feels like Sun have only created a few Swing wrappers simply to provide some components for this first release. Will there be any benefit of have two distinct lines of components (Swing and native JavaFX)? I dont really think so.

It is vital Sun address this matter more than any other if they wish to see widespread adoption of the technology.

Its a shame the first release didn’t have a full set of components as this is often one of the more important aspects of general uptake.
One of the first things developers will ask themselves is “How good are the GUI controls and layout classes?” and “Are these controls easily skin-able?”. At the moment the answer would be “Not good enough yet.”

“Yet” being the important word to take though. I am sure Sun will sort this out. In fact in a way I am pleased they didn’t rush a set of components out.
Anyone who has worked with Flex (mx components) at any serious depth for any serious length of time will know one thing – they are buggy as hell! The mx components (if you go back to Flash) have been re-written no less than 3 times from the ground up!
The latest iteration being in Flex Gumbo, not yet released. So not speaking for Gumbo as I have yet to review it in depth, but all previous mx components have been rushed and poorly written (hence the re-writes rather than fixes).

The ball is firmly in Sun’s court. The next release will be a vital watch point.

So, JavaFX v1.0 was released the other day and many people are quick to have a rant about it, so I may as well chip in too!

We have lots of commercial Java experience, both on the server and the desktop, so have kept a keen eye on JavaFX since it was first announced – which feels like ages ago, and its this point I will address first…

Its difficult to generate a community around a new technology which has been prematurely announced (i.e. before its even really in an acceptable beta) and delivered way later than first scheduled (approx one year behind schedule).
Encore are a company I can only imagine Sun would love to become an early adopter of JavaFX – cross-platform, multi-device, many on/off-line applications (and RIA’s) developed by us and of course lots of Java experience. But its been difficult to get behind the technology. We need to be sure it can deliver both technological advantages and user experience above its closest competitors (Adobe’s AIR/Flex and to some degree Microsoft’s Silverlight).
Since first announced, its felt very alpha in its development. We, the community, have been informed what it will be, but it just hasn’t yet delivered.

Now lets take a step back and address the points we like.

- The JRE.
The maturity of the underling technology (the Java Runtime Environment) cannot be overlooked. One of the biggest gripes we have with, for example, the Flex framework, is it is bug ridden. Start doing any kind of serious project with it and you cannot get away from this. The mx components have been completely re-written no less than three times now! And they are still buggy. This slows development, there is no getting around it. Ask any developer who has done any serious stuff with the Flex framework and they will be able to testify to this. Hopefully with Flex, this will improve now that the framework is open-source.
Java is very mature and so we shouldn’t see soo many issues in this department.
The JRE is also leaps and bounds ahead of the Flash Player in terms of functionality, along-side the fact there are tons more Java developers (and more experienced) out there than actionscript developers, which as an employer, is also a key point. Finding decent actionscript developers is tough compared to experienced Java developers and this isn’t because of demand, its because actionscript 3 (I pinpoint 3 because 2 was half-baked and the Flash Player AVM1 was pants compared to AVM2 – hence incomparable to Java and the JRE) is a relatively new language and most actionscript “developers” have come from a creative/design background as opposed to programming. We like designers to do design and hard-core coders to code and for the two teams to collaboratively work together to create great results.

- The delivery mechanism.
The fact JavaFX is part of the JRE, anyone with a recent JRE will already have the JavaFX runtime installed.
Sure, there are always going to be cases where a users JRE will need updating, but Sun have been making lots of effort to make this easy and a small download. As time goes by, this will just be less and less of an issue alongside Sun making the install experience easier and better. This is more a JRE issue than JavaFX as Sun have been overhauling the Java install experience anyway.

- The on/off-line capabilities and user experience.
Seriously overlooked is the ability to simply drag a running JavaFX application from the browser window to the desktop.
The coding of one application and the ability for end users to either run it from the browser like any other RIA or install it locally as a desktop application by simply dragging it from the browser window – this is cool. If the user does drag it to their desktop, you can leverage all the extra desktop functionality and thus create some great user experiences.
Adobe developed AIR to essentially fill this gap the Flash Player and Flex framework had, but they just haven’t thought this out as well as Sun in my opinion. If you take an Adobe route and want browser and desktop application, you end up writing two separate applications and have two separate end-user install requirements, the Flash Player for browser app and AIR for the desktop app.
Take the proposed Sun route, you have only one requirement, the latest JRE. You also have only one app to develop.

- Mobile.
Not yet delivered (though apparently in Spring 2009) is JavaFX Mobile.
Given that there is a JRE on practically every mobile phone in the wild, you can see where JavaFX plans to reach.
Compared to the Flash Player in this department, JavaFX would win hands down. Flash Player on mobiles, named Flash Lite, is years behind its desktop counterpart (Flash Lite is still the old AVM1 running actionscript 2 coded apps) and Adobe are only now starting to talk about AIR on mobiles in the future, no firm dates.
Even if Adobe updates Flash Lite (so AVM2 and actionscript 3), it will still seriously lag behind Java functionality on the devices.

Brining it all together, if Sun can deliver and then get companies to adopt, JavaFX is going to be a force to be reckoned with. Develop one application that can run through a browser, on the desktop, on mobile phones/devices… brilliant. But its a big ask. So far just delays and a beta-like release. I guess more will become clear how this is going to pan out over the next few months.
Many are quick to write Sun off – I am not soo quick.