Home

Sun has long touted JavaFX as a tool to provide interactivity to a wealth of platforms. It was introduced at a time when Windows Mobile was considered the interactive platform to compete against. But since then a number of credible alternatives have surfaced and Sun has made little traction. Anglin suggests that the adoption of Flash for the Blackberry might just spell the end of JavaFX.
Apple captured the creative heart of the mobile developer mindshare with its wild successful Objective-C/Cocoa based iPhone platform. Microsoft has even gotten into the game with its Silverlight which is also being ported to mobile platforms. Adobe has dominated the desktop with Flash, and is now pushing hard to achieve the same kind of success on mobile platforms.
Anglin notes that JavaFX has been out for over two years with little support besides Oracle-Sun, Sony, and Ericsson. It faces stiff competition in the mobile world from Adobe Flash, Apple Cocoa/Objective C, and Palm WebOS. He does not see much hope for JavaFX especially with Blackberry deciding on Flash. He said that JavaFX desktop faces an even harder battle against Flash and Silverlight. He noted, “More and more, JavaFX seems to be all but dead now.”
Do you know of anyone having success with JavaFX, or has its lost its luster?
http://ablog.apress.com/?p=1539#more-1539

Me being a RIA developer, I will tell u JAVAFX will be die sooner due to multiple reasons.
1) The Client plugin which is needed to run a JAVAFX applet is very heavy, I am sure people will say consumer JRE will save us(ask yourself will it be possible?) Flash player is hardly 2MB that also Flash player 10 has two run times (AS2& AS3), still way way better than a 17-20MB JRE.
2) Syntax is really not developer friendly, I have worked on a JAVA Based RIA's like Nexaweb(XML And JAVA based coding), ECHO 2. Both had something better syntax and development methodologies. Have you seen FLEX MXML and AS3 a developer can in fact reuse both of them independently.
3) Sun itself is no more to drive the show, Oracle has a huge crush of JSF, in fact they are too very biased towards JSF. Check out http://www.oracle.com/technology/products/adf/index.html
The only best feature I liked in JAVAFX was the capability of pulling out a a applet application from browser to desktop. That's really cool.

The JavaFX language does has some features that are too good to go away. My favorite feature is binding of properties, sequences, object literals and the scene graph.
The desktop runtime has its problems, licensing, it is unclear what right you have to distribute the runtime if webstart and applets are a nogo. I never really learned to like webstart, though it is good for demos of java software.
Threading, JavaFX has no multithread support, which makes it more difficult to integrate Java and JavaFX code.

I was on the Sun developer advisory council for a number of years, and saw many things early, and got to provide some feedback as well (and most of it was never listened to it seems). Doing easy app development for web delivered content was something that they of course had interest in. JavaFX is their attempt at trying to close the gap on the desktop experience while continuing to learn more about what people really need to make Java work on the desktop for web delivered apps.
Being able to drag an applet off of a web page and continue to use it independently of the browser is pretty much the only additional thing I needed. But, there could be a complete revolution if the java applet was given access to the DHTML/CSS content of the web page so that it could be used instead of javascript for rendering and dynamic updates to the web page.
Once that was in place, it would be pretty simple to create a full HTML JTextComponent that would allow such content to be delivered without a browser, and then presto, no more browser portability issues!
But you know what? Sun still doesn't understand the desktop. All of their engineers seem to have, forever, done server software development. So they are used to simple, primative UIs with simple and rather expensive to use APIs because they've not found out what is bad about Swing and the desktop experience, yet.
Tables and lists seem to be the only important issues. Look at netbeans for example. It has absolutely terrible use of the EDT for performing event work, instead of just dispatching it (Event Dispatch Thread, not Event Handling Thread is the name!). So it seems clear to me, that all of the issues that exist on the desktop with Java are still to be dealt with.
It's sad that they never hired any real GUI tools developers. The entire Solaris management tool set should be Swing Java apps by now, and they should be selling all kinds of Java desktop applications into target markets.
Clearly the desktop has not been interesting to Sun.

Like Siva explained in his post, the Syntax keeps even Java developers away from JavaFX as heavy weight run-time keeps implementors worried about.
We don't know why the hell Sun did come with a complete set of new syntax while failing to utilize the huge community of Java base's exisiting learning and knowledge. Probably thought wrongly to follow Abode's ActionScript synta, etc. which was also frustating.
With Google is trying to stamp in the market with its Go language, Sun/Oracle has to be extra careful.
Who wants a new syntax? all want is a new features, improvements, etc. with lighter runtimes.

As a long time java developer, I had more fun coding with JavaFX than I have had in a long time.
It was fresh, it was original, it was quick to see/touch good looking results.
Wrote a pretty nifty (in my opinion) game with it.
Attempted to use it for a customer-facing app...ran into some memory consumption issues (which may have been resolved with last point release) but I had already re-written app as html/javascript/plain applet. :(
Would like to re-write it in JavaFX to eliminate all the cross-browser support issues that javascript/html/css brings with it but would really like to wait to the next (Soma?) release comes out.
I still have hope.

JavaFX it is dead since day 1!.
It is absurd what Sun did. We just need the Java language have closures and maybe a form to declare Java2d/Swing GUIs with XML/XUL, Thats was all about and not to create a new language, syntax, tools and so on. The JRE6_10+ it's ok for deployment but I agree it should be more lightweight somehow for RIA deployment.
Sun never did good for the desktop. Java is a server side language so maybe was better bet to integrate with Adobe Flash/Flex than reinventing the wheel with JavaFX.
Sorry but JavaFX It was just Sun hype.

New books are being released. The Java app store beta is out, and has some nice apps in it. Larry said he wants JavaFX in OpenOffice (we'll see about that).
Personally, I still see plenty of potential with JavaFX. It has the furthest potential distribution of any Mobile/Desktop/RIA platform (and it's the only mentioned platform that does all of those things fully). It does have a very nice syntax (I prefer it to MXML/Action script, which is too much like HTML/Javascript for my liking). It also makes rich UI dev easy. You can do cool looking stuff with it much easier than you can with plain old Swing. Also, it has wrappers on Swing components.
Finally, as for download of the JRE - the consumer JRE is 3-4 megs. And it's already out there. Plus, the JavaFX plugin is comparable to the Flash runtime (or Flash updates) in download speed. When I ran mine, it downloaded and installed quickly.
JavaFX still needs work, but it's coming along nicely.

Let me substantiate that:
- It's got a non standard scripting language. The whole point of this language seems to be that it is something else than what you might be used to. I'm not actually aware of any interesting features that this language has that make it more interesting/suitable than python, ruby, groovy, javascript, or even vb script. It's a missed opportunity. Language neutral was the way to go. Imagine we'd all be using jruby or groovy to program to the Java FX framework instead.
- It's basically written on top of a bunch of technologies that have so far failed in the market: AWT, Java2D, Swing are hardly technologies that get any graphical designer enthusiastic while most developers who had to work with these technologies might be less than enthusiastic as well. I can sympathize with the desire to reuse existing stuff but I don't think reusing your past mistakes is going to help when launching something new.
- The tooling was and is not there. Sure there's the sun provided stuff. But like everything they ever attempted that involves a UI, this has its obvious short comings. More importantly, it is poorly aligned with competing tool chains. Like those provided by Adobe that any self respecting designer depends on.
- Sun launched their betas and then their 1.0 with spectacularly crappy demos. The word 'bad' doesn't do it justice. Whomever allowed that to happen should not be in charge of any commercial product launches ever. They proved only one thing to potentially interested designers/developers: this sucks. Go look for Java FX demos, applications, etc (anything!). Absorb the general crappyness, the poor design, etc. Now do the same for Silverlight and Adobe Air. Not the same ball park. Not even close. I've never encountered Java FX in the wild. I'm sure there is some dark corner of the internet that has some Java FX to offer but I don't seem to have ever encountered such corners. This BTW. is a repeat of earlier mistakes with applets, swing and web start.
- Sun forgot about the competition, which made none of the above mistakes. Silverlight and Adobe Air launched around the same time as Java FX. Unlike Sun, MS and Adobe didn't introduce a new scripting language or built on top of failed offerings and you can't exactly accuse Adobe of screwing up in the tooling department either. There were some pretty cool demos and shortly after launch a lot of applications.
So yes, DOA.
What were they thinking?! Here's a company that has majorly screwed up everything they ever did that had a UI. Seriously, name me one SUN software product that is known for its pretty & usable UI? Yes, right: pretty hard. Netbeans? Open Office? All pretty clunky and years of fixing the problems hasn't really resulted in something competitive. Open Office survives only because it is free (as in beer, most of its users couldn't care less about OSS). Feature wise it is reasonably functional, so people tolerate the bad look and feel. Open Office looks like the poor mans office. It's basically ms office without the fancy UI. Except they never really evolved beyond office 97 as the role model. Netbeans looks and feels like it was engineered by engineers for engineers. I know some who like it. I know more who like IntelliJ or Eclipse better.

It's got a non standard scripting language. The whole point of this language seems to be that it is something else than what you might be used to. I'm not actually aware of any interesting features that this language has that make it more interesting/suitable than python, ruby, groovy, javascript, or even vb script. It's a missed opportunity. Language neutral was the way to go. Imagine we'd all be using jruby or groovy to program to the Java FX framework instead.

"Non-standard"? Is there such a thing as a standard scripting language..? :)
Can I be cheeky and ask whether you've actually USED the language? (I mean, aside from compiling Hello World.) If you'd given it a go for more than 5 minutes you'd realize that 'non-standard' syntax is actually incredibly adept at coding GUIs and hooking up all the MVC plumbing sans boilerplate. It's not a general purpose language like Java or Ruby, it's a DSL specifically tailored for graphics, animation, and UI development. (JFX is to UIs as SQL is to databases -- that's why the syntax looks the way it does.)
I'm sure there's lots of things you can criticize JFX for, but JavaFX Script isn't one of them. If you really see zero value in it I can only assume you've never spent any significant time actually trying to code slick graphics and animations using "standard" (as I assume you'd call them) languages! :)

Face it. JavaFX is a dead technology with no future. Sun people talks how great it is JavaFX but there only at Sun. The rest of the world is disapointed and does not want to know nothing about JavaFX. Even the name does not deserve to be called "Java"FX should be called SunFX.
Good luck to the people that are using JavaFX but it will be just a lost of time using it.

Yes, ECMAScript is standarized with dialects such as JScript, ActionScript and JavaScript.
lol, another way of saying this is "ECMAScript is standarized, but no one respects it".
Talking about JavaFX I just fell it will finish in the same bin where Go (Google) will rest unless it gives something new.

Well, Sun as we know is is dead. Eventually the Oracle acquisition of Sun will go through. What Oracle does with various Sun technologies is hard to say.
With JavaFX, Larry has already expressed interest. But that might have been BS passing interest for the sake of his presentation at JavaOne. But, it might be real interest because he sees UI as part of the overall puzzle, that ultimately helps their back end enterprise play. Larry knows how MS is able to leverage it's desktop dominance to help drive server side sales, and is keen to compete.
Anyway, regardless of JavaFX's fate under Oracle, JavaFX is nice technology. JavaFX script is quite nice to work with (and I very seriously doubt any of the detractors here have given it any trial beyond "hello world"). And just think of the potential distribution capability across desktops and devices. JME is already on the majority of devices out there (including Symbian and Blackberry based), and JFX is a simple add on to that. It's also a simple add on to JRE's on desktops.
And I have tried the new Java App Store (which allegedly Oracle is behind it), and it's created/written in JavaFX, and features mostly JavaFX apps. It's really, really nice, and many of the apps were quite nice.
What I do like about JavaFX is that it's easy to create UIs that embrace the new UI paradigm that is becoming more and more common - that is the iPhone style UI - with shiny buttons and other objects that move in an animated fashion. Also, look at Windows Media Center. It's the same style. Finally, if anyone here has been to Disneyland, and the Tomorrowland section, and an attraction there called "Innoventions". This attraction features the "home of tomorrow". This features all software from Microsoft, and all done in the style of Windows Media Center (or the iPhone style of UI).
Long story short, I believe this is where UIs are headed, particularly for consumer side, but more and more so for enterprise apps. The standard Forms based UI, with the traditional "File", "Edit", ... etc buttons across the top, is gradually going by the wayside.
Swing and SWT are really good at the latter. JavaFX is really good at the former.

Yes, ECMAScript is standarized with dialects such as JScript, ActionScript and JavaScript.

So Python and Ruby are non-standard scripting languages? Are you going to tell their devotees or shall I? :)
Languages are tools, some more specialized than others. Languages like SQL and JavaFX Script are targeted at solving particular problems. Others are more general purpose. There is no such thing as a 'standard' language, superior to any others.
Rather than bashing square pegs into round holes by making a single language fit every problem, learn several languages and pick a tool which suits the job at hand.

There is no such thing as a 'standard' language, superior to any others.

There are standard languages. You are mixing two orthogonals: standard and good.

Erm no, you're mixing "a standard" (a specification) and "the standard" (a convention or norm). For example, there are many image file format standards (JPEG, GIF, PNG, SVG, TIF, PSD) but not one of them could be called more standard or non-standard than the others.
The original comment criticized JavaFX Script as a non-standard language, then went on to suggest Python, Ruby, Groovy, Javascript, and VBScript as alternatives. Clearly the poster didn't mean "standard" as in a specification, because there isn't a single specification that unites those languages. Each has its own specification, but then so does JavaFX Script. So "standard"/"non-standard" clearly means something else in this context.
To restate: there are languages that adhere to given standards, but there is no such thing as a standard (or non-standard) language.

I dont want to hijack this thread with word games, so, this is standard language: http://en.wikipedia.org/wiki/C%2B%2B0x.
So, there are standard languages, and there are non-standard languages. Being standard does not make you good, and being non-standard does not make you bad, and vice versa.

So, there are standard languages, and there are non-standard languages. Being standard does not make you good, and being non-standard does not make you bad, and vice versa.

As explained previously, there are at least two meanings of the word "standard" depending upon context. One relates to a specification ("his qualifications are of the highest standard"), and the other relates to a norm ("it was a pretty standard day").
As stated, we're not taking about specifications here (the orignal posting makes no sense when interpreted that way, as already demonstrated), so why you posted that link is beyond me. Someone commented that JavaFX Script is non-standard, meaning "not normal" -- so I'd like to know what constistutes a standard (normal) or non-standard (not normal) language? Because in my mind there are no non-standard languages in the sense being discussed.

so I'd like to know what constistutes a standard (normal) or non-standard (not normal) language? Because in my mind there are no non-standard languages in the sense being discussed.

There is no such thing as a 'standard' language, superior to any others.

In practical, real-life, money-making world, c++ is the standard language superior to any other language usable in same problem domain.
What's in my mind, or your mind is irrelevant.
PS
got captcha: "laywoman noncallable"

That is excellent point,,
Since it is built on top of swing, awt, .. it can only take you so far...

It's got a non standard scripting language. The whole point of this language seems to be that it is something else than what you might be used to. I'm not actually aware of any interesting features that this language has that make it more interesting/suitable than python, ruby, groovy, javascript, or even vb script. It's a missed opportunity. Language neutral was the way to go. Imagine we'd all be using jruby or groovy to program to the Java FX framework instead.

"Non-standard"? Is there such a thing as a standard scripting language..? :)

Can I be cheeky and ask whether you've actually USED the language? (I mean, aside from compiling Hello World.) If you'd given it a go for more than 5 minutes you'd realize that 'non-standard' syntax is actually incredibly adept at coding GUIs and hooking up all the MVC plumbing sans boilerplate. It's not a general purpose language like Java or Ruby, it's a DSL specifically tailored for graphics, animation, and UI development. (JFX is to UIs as SQL is to databases -- that's why the syntax looks the way it does.)

I'm sure there's lots of things you can criticize JFX for, but JavaFX Script isn't one of them. If you really see zero value in it I can only assume you've never spent any significant time actually trying to code slick graphics and animations using "standard" (as I assume you'd call them) languages! :)

"Do you know of anyone having success with JavaFX"
No. Because none exist. (I say that tongue-in-cheek... but only partially)
"...or has its lost its luster?"
That presumes it ever had any. It didn't.
JavaFX *might* have had a shot 5+ years ago, and even then I doubt it. I *am* sure however that it has no shot now, and didn't even when it was first announced.
I'm all for people having ideas and putting out products... that's the way we all grow... but this is one that will go down in history as not a good one.

Sheeesh! We're hardly past the first bend and already pundits are trying to call the winners and losers. I can still remember the doom-laden predictions for Java shortly after it appeared in the mid 90s. And weren't we all supposed to be using Ruby on Rails by now anyway? Hmm yeah, see that's the problem with calling the election after just a couple of results are in.
JavaFX has a lot of ground to make up, but at its core it is by far the stronger technology simply because it's custom built for the job at hand, rather than a bastardization of pre-existing languages etc. Sure, superior technology doesn't always guarantee popularity (Betamax, Playstation 3, Apple Mac...), but with things a long way from settled it would be silly to rule out the power of JFX at this stage.
JavaFX Script takes a little bit of getting used to at first, but you quickly realize its syntax has enormous benefits over Java etc for user interface coding. If you're having trouble I can recommend one of the JavaFX books like "Pro JavaFX Platform", or the new "JavaFX in Action".
As it currently stands JavaFX was last out of the traps and still catching up, but it has by far the biggest potential of the three main VM-based systems. Will this be enough to catch up and overtake its rivals? Who knows! The finishing line is still too far off for predictions to make any sense.

I agree that JavaFX was DOA but the reasons have nothing to do with it's technical merits or good or bad Sun is at UI.
Consider a hypothetical new website called Mugbook. It's basically the same as Facebook but technically superior in every way. Would it succeed? Not in a million years. The reason is that there are already competitors with huge amounts of market share and more importantly, mindshare. People have too much invested in the other options and even if you could make it worthwhile to switch, your more entrenched competitors won't just sit still while you steal their market. They'll just copy any improvement you make (unless your competitor is Sun: they'll be too busy designing exorbitantly expensive key-fobs that flash colors.)
Perhaps they could have gotten somewhere by starting a standards-based alternative to Flash. But as it is, they just fell into the trap of thinking it's still the 90's and that because MS came out with Silverlight they have to do the same.

yes I agree JavaFX was dead on first day. They enter into game 10 years late (all along they knew about it).
I loved Java Swing so much but not much work coming compare to JSP/Servlet combo. Any ways now Flex 4 coming edition is was ahead of game. They also have light Flex 4, Flash 10 & other goodies for mobile runtime.
so long...

I think it's funny that people complain about Sun creating a new domain specific language for creating UIs, then suggest that Java programmers learn .NET/Silverlight and ActionScript/Flex/Flash instead. People who cry about their favorite language not being used to create JavaFX (like Ruby) have obviously not put any thought into Sun's reasoning, and not done any JavaFX programming.
If JavaFX had all the tooling and required functionality today, I think the majority of Java developers would choose JavaFX over a non-Java solution because JavaFX is an all Java solution.
I saw a photo taken at Devoxx 2009 of a JavaFX tool that looked very much like FlexBuilder, but in NetBeans. At JavaOne 2009 I saw videos of a different kind of visual designer that looks more like Flash Studio. Plus, there are tools for exporting Illustrator and PSD files for use in JavaFX. Once these tools come out, I think JavaFX will finally be "1.0" and ready for prime time. Give it a year or so for people to adopt it, then we'll see that all the Sun and Java haters were totally wrong. There are tons of Java developers who are very eager to learn and use JavaFX once the package is complete, and who will use it to create real products.
Oracle has expressed an interest, and once the EU completes their Adobe sponsored delays and allows Oracle to complete the transaction, I bet some serious cash will be put into JavaFX.
What JavaFX *really* desperately needs though is a company like RIM to include JavaFX in their next generation product line, and for it to run on Android. It ran on Android in a JavaOne 2008 demo, so I suspect Sun is holding back a lot of very exciting announcements until they launch the next release.
Once HTML 5 comes out with the video embed tags, I bet it will be rare to find a site that uses Flash unless it is a RIA, since the majority of sites that use Flash just use it to display video. Then Flash and JavaFX will be on level playing fields.

There is always room for success stories. JavaFX ain't one.
None of the dominant RIA solutions are good enough. There is room for a new platform and probably canvas will provide.
JavaFX does not fail because of its poor technology. It fails because it has a bad steward.
Sun does not get it. Swing had three major problems that caused it to fail:
1. disgusting look and feel along with an obsession to replicate the platform; Sun should've created a unique L&F just like Flash did.
2. lack of components; Sun believes that you get things started and the free world just picks up the challenge; It did not work;
3. lack of good tooling; Sun believes that you can draw RIA from the bash shell prompt;
JavaFX is in the same hands. I stopped believing in Sun. Success just "happened" to them with Java. They never learned how to score.
Stay away from Sun. You will feel jilted time and again.

iPhone just killed BlackBerry. It's been loosing market share in the business and consumer space since iPhone came out.
I can't stand the ugly syntax of ActionScript/MXML.
I would love to develop JavaFX apps if it was using the Java syntax. Unfortunately, the JavaFX syntax is just as ugly as ActionScript/MXML.
I'm philosophically opposed to Apple AppStore, so I won't be coding in Objective-C.
As a java guy, I'd love to write RIA using a Java-like statically typed language. I would do Silverlight uses C# but I'm philosophically oppossed to anything Microsoft. They are just as evil as the Apple AppStore.
For a java lover guy, the only alternative for me is to do Android development. I'll stop if they become as evil as the Apple AppStore.
Android will kill the iPhone and JavaFX in both the smartphone market and the RIA space.

The best argument for JavaFX being a dead tech is how late it arrived to the market. It has a chance within the Java community to live on as a RIA solution but, won't expand much beyond that. I don't even think that will happen if they don't make it work cleanly with standard Java, libs and frameworks. This is what ticked me off about JavaFX. How could they not support Java arrays with out jumping through nasty hacks? Correct me if this has changed or been documented better. The best thing JavaFX has done for Java is the consumer JRE and plenty of Swing enhancements in Java 1.6.
For those poo-pooing Swing you don't know what you are talking about. Swing has come along way since 1.4. There are some great libraries and Look and Feels out there. I find Swing development very satisfying and I'm a former Visual Basic (yeah don't preach to the choir) developer, I hate WYSIWIG development IDEs for UIs. They suck at creating extendable and reusable components and screens. One of the many reasons of my abandonment of VB.
What appealed to me about JavaFX was the declarative syntax that made building UIs clean and structured without a lot of ceremony. It reminded me of the Groovy SwingBuilder with some niceties.
I am now playing the waiting game. My guess is JavaFX will not grow much further and adoption will slip. It probably already has. But, it has the potential to go the other way if Sun can fill the gaps that keep it restrained from larger adoption.
I think HTML 5.0 has potential. I dislike Flash, Flex, and anything Microsoft.

I agree.
I think that ever opinion must be in hold until Sun will release the final release of jdk7 with the consumer jre.
With the current jdk6 it is clear that javaFX cannot compete with Flash plugins, or Silverlight plugins, for obvious reasons.
We must wait for the jdk7: it will be a great and important jdk release that will give a new boost for java client development (applets, desktops, mobile...).

I think Flash and Silverlight being installed on every blu ray device that ships is going to... oh wait, hold on.
That would be Java. Java is a mandatory part of the standard. Hmm... And JavaFX just happens to run on Java.
Is JavaFX dead? Pfft... no... JavaFX is just getting started. Literally millions of devices are going to be carrying this stuff.
Now, lets look at this "supporting evidence" of RIM's passing over JavaFX.
- RIM has seen serious plunges this year in stock price
- RIM is now facing serious competition against their devices
- RIM is most likely to a continuation of its declining market share over 2010.
If anything is on the way out, its going to be RIM.

No. I believe there are lot of incorrect assumptions floating around especially from people who do have not understood full potential of JavaFX.
IMHO unless application uses a non-Java technology all around, I would always prefer Java based technology with exception some requirements do not allow to use it.
Integration of existing Java code is a best advantage using JavaFX plus it has good features like Binding plus it is also simple to learn and site has excellent tutorials.
If developer just want to display video I think, there may be lot of other alternatives.
JavaFX as a whole is a good alternative and worth trying.
Yes, JavaFX does require learning curve for some Java Developers who are new to scripting world or coming from non-Java side, but is worth.

The only best feature I liked in JAVAFX was the capability of pulling out a a applet application from browser to desktop. That's really cool.

That's a feature of the consumer JRE, not JavaFX, no?

We just need the Java language have closures and maybe a form to declare Java2d/Swing GUIs with XML/XUL, ...

Not to derail the debate, but what good would Java having closures do at this point? As to XML-driven GUIs, plenty of libraries do that, but don't seem to have gotten traction -neither individually nor as a concept- so again, what good would that do at this point?

Stupid isn't the word I would use but, definitely following a bad idea. Every good product (e.g Spring, EJB (good?)) that started with XML as the source of configuration is slowly going away from it. Those that aren't are going to get abandoned (Ant, Maven). XML was a good stop gap before Rails showed us a framework using convention over configuration is a good idea. Especially with the power of a good terse language backing it like Groovy, Scala, or Ruby.

The referenced blog states that Blackberry now including Flash is a death knell for JavaFX.
What the blogger forgets is that Blackberry already fully supports Java ME, and JME is one of the main development platforms for Blackberry.
And JavaFX will run on JME with a simple download of the FX runtime (very small and fast, I've tried it on a fresh Ubuntu install).
So, basically, Blackberry already supports JavaFX. As does Symbian, as does about a billion phones.
Also, the JRE is pre-installed on something like 95% of all desktops and laptops. Again, the JFX runtime is a very small and fast download that happens automatically when accessing a JFX online app.
JavaFX has huge distribution potential.
Add in the new Java App store (which is supposedly driven by Oracle), and you'll start seeing lot's of viable JavaFX apps.
I already have. I've tried the Java App store app beta (and so should all the other detractors here). It's a really nice looking, easy to use, fast, application, and features a bunch of really nice JavaFX (mostly) applications. Most of it is games, and smallish calculator, weather applet, type stuff. But it's all really functional and very attractive.
Add to that the really nice syntax of JavaFX script. And the already existing nice tools (in NetBeans, and an Eclipse plugin), and a bunch of really good books coming out (or already out), and Oracle/Larry supposedly behind JavaFX, and I see a bright future.

What the blogger forgets is that Blackberry already fully supports Java ME, and JME is one of the main development platforms for Blackberry.

No, the blogger is not forgetting anything, JavaFX on Java ME simply does not exist.
Try it, go to:
http://www.sun.com/software/javafx/mobile/index.jsp
You will read a nice pamphlet about how Java FX mobile is going to take over the world and then you get redirected to the main JavaFX page. Nothing mobile. Two years later after the initial promises, and absolutely nothing to show for it.
If only this was JavaFX's main problem... The simple truth is that JavaFX has gained absolutely zero traction while its competitors are available everywhere. Even Silverlight has been such a success that not only does it have a Mac runtime now, but Microsoft is actually extending it to the desktop:
http://tirania.org/blog/archive/2009/Nov-23.html
Anyone who seriously thinks that JavaFX has a remote chance of gaining some mindshare is severely deluded. In one year, we won't even be talking about it any more, like most of Sun's innovations of these past ten years.
--
Cedric

Anyone who seriously thinks that JavaFX has a remote chance of gaining some mindshare is severely deluded. In one year, we won't even be talking about it any more, like most of Sun's innovations of these past ten years.Cedric

I personally think it won't succeed in established markets such desktop or web based RIA. Probably it'll have some success in new and niche markets such as blueray or smart tvs and such. But that depends on success of these niche markets! Javafx seems just too ambitious to me, it tries to be everything from desktop UIs to blueray contents! In the end of the day, like every other such ambitious technology it'll settle on its own niche market. But then blueray for example is itself a very over-engineered piece of technology, so perhaps in some point in time we'll see stripped down versions of it, with javafx replaced with something smaller!
Ara.

For JavaFX to succeed it does need good tooling. On the Eclipse side we [Exadel] have been working on JavaFX plug-in for Eclipse. The plug-in will soon be open source and we have started working on visual JavaFX script editor.
Max
http://mkblog.exadel.com

Fantastic!
Also, another poster pointed out the visual tools demoed at JavaOne. So presumably that will be released soon.
See everyone ... there are tools on the way.
And if a third party company like Exadel is investing in JFX tools, it's a strong indicator that JFX is not DOA.

Hard times for JavaFX - why?
Keeping my personal preferences apart, I have put together a set of reasons why JavaFX is not the framework of my choice.
All of this is based on my "in-the-trenches" experience of using JavaFX for a enterprise application development
I am by no means a java FX expert, so anybody can jump in to correct my interpreations and analysis.
1. Lack of "real" samples that help the enterprise developer
I am not talking of those samples abound on the net about how you can transform a circle with 3D effects, create flying saucer with shadow effects in a couple of lines of code - Those examples with 100% wow are cute not useful. Thank you very much.
I am talking of serious samples that work and address business case with a some amount of "Wow" in it.
2. Lack of a reference implementation.
Seriously - Where is the Java PetStore or any of the new blueprints implemented using JavaFX? There are none, because they cannot be implemented easily.
Where can I find a few core JEE patterns and robust server integration examples. There are none.
All you have is a simple PullParser based XML voting for a hand held Yawn....
Sure, everything can be implemented by myself IF I had the time. Surely time is lacking in most typical enterprise projects. Everything needs to be done fast and cannot afford to spend time on plumbing and mundane things
3. Lack of Standard and mature components. This is the most important thing for the failure of adoption of JavaFX. Let me provide a few examples
a) There is no scrollpane. Believe it or not. Ofcourse folks that claim SwingScrollPane can be used are in for a surprise. All serious FX widgets are Nodes. And Scroll Pane cannot hold Nodes. It can only hold Swing Components (a certain subclass of Nodes that wrap Swing Components)
The solution: You make your own srcoll bar,
Then you create your node with translate binded with scrollbar displacement. Finally you set the clip property of your scrolled node for the display area.
Sounds interesting. But does it sounds interesting when you are really short on time to implement and deliver a project?
b) How about Menu?
Oh no... no... Dont even mention it.. The JavaFX team has great image transition effects for you but no menus. You will have to get them from nightly builds of JFXtras project - not even 0.5 release build (God bless them)
c) How about a decent layout mechanism for complex layouts.. I guess asking for that is blasphemy. Why on earth do you need that? You cannot render on a mobile device. Seems like JavaFX team is more concerned with platform agnostic nature than providing components for atleast the desktop.
Again thanks to the JFxtras project, we have a good port of MigLayout. But the MigLayout has its problems. It cannot do translateX and translateYs correctly and cannot center the components especially within a custom build scroll pane - even though VBox and HBox can !!
d) No tabs - Wrapping Swing Tab item can only house SwingCOmponents and not Nodes
e) No textArea, but I could wrap a Swing Text Area. But what about the additional attributes like visible, disabled etc..
Somebody just starting out cannot figure these out immediately. I can go on with examples, but let me stop here on this topic.
4. Books - Sure there are few books. I have read all of them. They are good to the extent of covering the standard stuff about syntax, binding, animation, image manipulation etc.
As far as I can remember only the Apress book had some coverage of JFXtras and their widgets, especially MigLayout with sort of real life scenario.
5. And what about addressing practical issues?
There are memory leak issues when recycling even the simplest of Nodes bound to a stage/scene.
This link to my blog http://objectsource.com/blogs/?p=10 covers this in great details.
Quoting from my own experience:
I learnt GWT begining of this year and implemented a bunch of projects using it. After going thru some theory, few examples, books and google search, I could develop pretty good enterprise applications. With the aid of Ext-GWT, Snmart GWT, I could roll out well designed apps pretty fast (Again components anybody? Is javaFX team listening?)
Comparing that to javaFX development, I am taking thrice as time to roll out fairly nice looking UIs.
I did not have much problem with back-end integration as i could use all the back end APIs I want. I have spent significant portion of my career in middleware and I was thus comfortable with integration piece.
Hope this helps anybody evaluating JavaFX
Cheers,
Srikanth Shenoy
ObjectSource (http://www.objectsource.com)

All good points, particularly in this early stage of JavaFX development.
However, traditional enterprise apps are not what the designers of JavaFX have in mind. That's already covered by Swing, SWT, and the myriad web frameworks out there.
You want forms based, data input/output UIs for enterprise CRUD type apps - use a web framework, or if you want a desktop UI, use Swing or SWT/Eclipse RCP.
But if you are looking for something with more bling or animation or slickness, and to build a UI for more consumer oriented, or entertainment oriented, applications, JavaFX is the way to go. And frankly, Swing, SWT, or Web frameworks weren't really covering that niche.
Check out the iPhone UI, or Android, or Plam Pre, or Windows Media Center, or any Flash games .... that is the type of UI development JavaFX is aiming for, and filling a gap in the Java world that was previously left unfilled by existing Java UI technologies (at least not filled very well).

All good points, particularly in this early stage of JavaFX development.

However, traditional enterprise apps are not what the designers of JavaFX have in mind. That's already covered by Swing, SWT, and the myriad web frameworks out there.

You want forms based, data input/output UIs for enterprise CRUD type apps - use a web framework, or if you want a desktop UI, use Swing or SWT/Eclipse RCP.

But if you are looking for something with more bling or animation or slickness, and to build a UI for more consumer oriented, or entertainment oriented, applications, JavaFX is the way to go. And frankly, Swing, SWT, or Web frameworks weren't really covering that niche.

Check out the iPhone UI, or Android, or Plam Pre, or Windows Media Center, or any Flash games .... that is the type of UI development JavaFX is aiming for, and filling a gap in the Java world that was previously left unfilled by existing Java UI technologies (at least not filled very well).

Agree 100% with all your statements.
But my circusmstance is a bit different - This is where technology decisions are made for marketing purposes.
It is for these scenarios of typical enterprise app development that my observations on JavaFX apply.
Nothing against the really nice graphics and effects in JavaFX.
BTW, GWT was my original choice for the problem at hand.
But you do need to remember that JavaFX is vying for that coveted enterprise app development pie where majority of any dollars are coming (LOTS more than cute flashy UI, gaming and handheld space combined.)
Also something to note is that Swing is no longer actively developed at Sun. Swing labs support is discontinued. Swing developers are moved into JavaFX team. So, as far as
Sun is concerned, (if they had their way) JavaFX is THE future of typical enteprise app development as well.
The implicit message from a long term perspective from Sun is clear - JavaFX or perish. Only time will tell, what will perish (Pun intended)
--Srikanth Shenoy

But Sun doesn't need this demo and library. They prefer bouncing balls.

Thanks Sergey.
That reminds me. Yes. I did download CrudFX a month or so back.
Your contribtuion to enterprise JavaFX development goes without saying.
Since you have been in JavaFX arena for a long time, there are various versions of your demo application (DerbyDemo) floating on the web (Links from jfxstudio, malankov.ru etc.) - most of them I believe are for older versions JavaFX and did not compile with JavaFX 1.2 when I imported them into NetBeans.
May I request you to
a) Include the source of demo application (Derby Demo) along with CrudFX download? That will give users a perspective with handy samples for UI component usage.
b) Could you please have a English version of javafx.me along with licensing info for CrudFX (i.e. non-LGPLed version for OEM-ing etc.)
-Srikanth Shenoy

Did you try binding javafx.scene.layout.ClipView to a couple of javafx.scene.control.ScrollBar's?

4. Books - Sure there are few books. I have read all of them. They are good to the extent of covering the standard stuff about syntax, binding, animation, image manipulation etc. As far as I can remember only the Apress book had some coverage of JFXtras and their widgets, especially MigLayout with sort of real life scenario.

Well "JavaFX in Action" was only release a couple of days ago, so not sure if you're read that, it's a bit more practical than some of the others. The Apress book was written by the guy behind the JFXtras project, so that's why it features his project so much.

I learnt GWT begining of this year and implemented a bunch of projects using it. After going thru some theory, few examples, books and google search, I could develop pretty good enterprise applications. With the aid of Ext-GWT, Snmart GWT, I could roll out well designed apps pretty fast (Again components anybody? Is javaFX team listening?)

That's because you're jumping into a project which is already quite mature, and has been through several major enhancements already. The 1.0 release of JavaFX was less than a year ago -- try downloading a version of GWT from its first 12 months and see how much was missing (I know, I worked with it right from its initial public release!)
At this moment you're right, there isn't enough of the API to make JavaFX a viable platform, too much is still unfinished. But Sun are filling the gaps quickly, and the 1.3 release will have a lot of the bits you've complained about, as well as even better scene graph and binding performance. It needs to mature quickly if it's to stand a chance against Adobe, and I think Sun know this.

Did you try binding javafx.scene.layout.ClipView to a couple of javafx.scene.control.ScrollBar's?

No I have not tried that.

4. Books - Sure there are few books. I have read all of them. They are good to the extent of covering the standard stuff about syntax, binding, animation, image manipulation etc. As far as I can remember only the Apress book had some coverage of JFXtras and their widgets, especially MigLayout with sort of real life scenario.

Well "JavaFX in Action" was only release a couple of days ago, so not sure if you're read that, it's a bit more practical than some of the others. The Apress book was written by the guy behind the JFXtras project, so that's why it features his project so much.

Thanks. I will try to grab your book and take a look.

I learnt GWT begining of this year and implemented a bunch of projects using it. After going thru some theory, few examples, books and google search, I could develop pretty good enterprise applications. With the aid of Ext-GWT, Snmart GWT, I could roll out well designed apps pretty fast (Again components anybody? Is javaFX team listening?)

That's because you're jumping into a project which is already quite mature, and has been through several major enhancements already. The 1.0 release of JavaFX was less than a year ago -- try downloading a version of GWT from its first 12 months and see how much was missing (I know, I worked with it right from its initial public release!)

At this moment you're right, there isn't enough of the API to make JavaFX a viable platform, too much is still unfinished. But Sun are filling the gaps quickly, and the 1.3 release will have a lot of the bits you've complained about, as well as even better scene graph and binding performance. It needs to mature quickly if it's to stand a chance against Adobe, and I think Sun know this.

Right. But hasn't JavaFX has been around for almost 3 years now in different variants?
The way I see it is:
Both JavaFX (in a different avatar) and GWT were originally presented in JavaOne 2007.
One just needs to track their growth path.
Hence saying JavaFX has been around only for one year is not completely true.
As you can see, component frameworks like CrudFX have been around for as long as JavaFX existed.
I am just surprised that any other ecosystem around JavaFX started building up only towards the end of last year. The pace is also very slow.
At this point, it would be very tempting to ask why I am only complaining without contributing.
Well, I am not an expert. Folks with breadth in app development and architecture can hardly contribute to the development of depth with a framework.
And seriously it is Sun with its deep pockets (not so deep anymore.. But still..) should have nurtured the development of JavaFX ecosystem in all these three years
But as Sergey puts it - They want bouncing balls. Not enteprise app development with JavaFX
I might sound as too complaining, but the reality of today is that enterprise app development with JavaFX is very frustrating and time consuming exercise. No project with delivery deadlines will gravitate towards such a framework as of now.
I want JavaFX to be a viable platform for all things Web 2.0 UI. I hope the competition gets the best out of it. I hope folks at Sun are listening (Got Components...?)
- Srikanth Shenoy

<blockquoteRight. But hasn't JavaFX has been around for almost 3 years now in different variants</blockquote>
JavaFX went through a long gestation period were various language features were trialed. The JavaFX Script of three years ago is a very very different beast to the 1.0 release from earlier this year. The language is quite innovative, and so took quite a while to develop. Until the language became more stable the final APIs couldn't be written.
Unlike with GWT, that experimentation took place in the public domain. So it's a bit unfair to say JFX has been around for 3 years, if the first 2.5 years were about speculative prototypes and experimentation.
As far as books go, none of them will have a lot to say about developing business apps, simply because JavaFX isn't fit for that purpose yet. The Apress book "Pro Java" features a lot about the JFXtras library which helps plug some of the gaps for now, and the new Manning book "JavaFX in Action" has a lot of practical examples and projects for many different types of application. I'm not familiar with any of the other books, but I suspect every book is 75% about animation right now.
Sun are having to start at the ground level, so that's why a lot of the demos and books are about core graphics stuff. You need your scene graph APIs working before you can begin to build extra layers on top, like controls. As 1.3 and 1.4 are released you should see more of those extra layers appear, and hopefully some of the books will be able to devote more pages to business apps rather than games.

Joseph your spot on with your analysis. That is one of the things that really frustrated me when digging into the JavaFX. After a couple of iterations of API changes and having to update my apps I just got frustrated and stopped. Well that was one of the frustrations there were others that caused me to walk away.
Sun has made this mistake before as it is not unlike how they have managed Swing. Early days it sucked big time but, now it is robust and much easier to use. Look at how people put Swing down all the time. They are clueless really at what is possible and available for Swing. It is the baggage of the previous versions that lives on and keeps Swing from being more prevalent.
JavaFX even in it's short life span is not only dealing now with the Swing baggage but, also it's own.
JavaFX does have a lot going for it. The cornerstone SceneGraph API for builting UIs is fantastic. The binding is excellent and it would be great if it could be ported to Swing. Thank God for JGoodies but, it is getting long in the tooth. If Sun wants this to be the Swing replacement they are screwed unless they can gain community trust through significantly better marketing of JavaFX's capabilities.
So I am reluctant to hang it out to dry but, Sun has boffed it again on another technology when if they would have waited for a more public release when more of the things people are complaining about are built in. This thread probably would have been moot.

Enterprise controls will appear at some point.. maybe version 1.3 or 1.4. The real question is when people will start building enterprise applications with JavaFX. Rich JavaFX-based UI's that are connected to enterprise back-end (Java EE, Seam, Spring). Adobe has done a great job telling that Flex can be used to build enterprise applications. With JavaFX, you get bouncing balls.
To see a real enterprise-level application, you can run this Seam Hotel Booking application built with Exadel Flamingo.
Max
http://mkblog.exadel.com

To your comments of JavaFX being on hard times, I would like to offer this thought:
Do you think that Sun/Oracle can afford to simply cede the RIA market to Adobe and Microsoft much less JavaScript/CSS?
In my opinion JavaFX is Sun's strategy for disrupting their own established client technologies, particularly Swing, and perhaps Oracle's (ASF) as well. As with any disrupting technology, the features and performance of the new technology are going to be less than the existing ones, at the beginning. Not having any inside scoop but referring to JavaFX's public Jira site, it seems that Sun is actively creating very necessary components for enterprise usage.
Having used JavaFX for small projects, I feel that the binding, triggering, and certain other features of JavaFX are best in class. JavaFX has learned many a good trick from Objective C. I shall be eternally grateful for not having to program in XML. There are some indications that the next version's font rendering features will rival those of Flash/FLEX, especially important for non-English-speaking markets.
In summary, there is a lot for Sun/Oracle to do, and there will be a great market battle ensuing, but I have to say it is more than premature to count JavaFX out either from a business or technology perspective.

It seems that whenever there is a new technology, that's not some open source framework, sooooo many posters on these forums completely close their minds to it, especially if it's from Sun or the JCP.
The same thing happened with EJB 3.x. In spite of EJB 3.x being really really good and easy to work with and really powerful, and huge improvement over EJB 2.x, the Spring fans will always chime in that it sucks, because it's not full AOP, or it's part of the standard, or it needs an EJB container, or something.
Anyway, the same is happening here with JavaFX. JavaFX is still young (less than a year has passed since 1.0 was released, prior it was all open experimentation), and still in active development, and people here are proclaiming it's DOA. That attitude is ridiculous, and frankly ignorant.
Now, that being said, if it doesn't have whatever feature/functionality you're looking for, simply state that it's not ready for your use case as of yet, and if it gets that feature/functionality, you'll take a second look. But to simply declare it DOA is just plain stupid. But then again, it's your loss if you do that.
I've been singing JavaFX's praises. In spite of still missing features, and still needing refinement, I'm seeing a lot of goodness in it right now, and a lot potential in the future. If it keeps progressing at it's present rate, I see JavaFX as being a more attractive choice than Flash/Flex (I've never been a big Flash fan), or Silverlight (too tied to .Net, MS dev tools, and Windows, and it's hard to trust MS for cross platform support). JavaFX sits on top of the awesome JVM, which is fully open and cross platform and very very very powerful, robust, and efficient.
So I'm kind of rooting for JavaFX to succeed, and think it just might do that, especially if Oracle gets fully behind it.
But I just want to say to the detractors - don't be such crumudgeons. You don't have to like it now, or ever. But give it a chance, and don't dismiss it out of hand.

It seems that whenever there is a new technology, that's not some open source framework, sooooo many posters on these forums completely close their minds to it, especially if it's from Sun or the JCP.

The same thing happened with EJB 3.x. In spite of EJB 3.x being really really good and easy to work with and really powerful, and huge improvement over EJB 2.x, the Spring fans will always chime in that it sucks, because it's not full AOP, or it's part of the standard, or it needs an EJB container, or something.

You would probably still be using a form of EJB 2.0 if it wasn't for Spring's pressure on the market to make something better. Sun's version of Dependency Injection won't even mature until JSR-330 and 299 are released.
Your not helping your argument by slandering those who like Spring and open source and it's encouragement of innovation in EJB. Is this a kool-aid drinker calling out kool-aid drinkers?

JavaFX is still young (less than a year has passed since 1.0 was released, prior it was all open experimentation), and still in active development, and people here are proclaiming it's DOA. That attitude is ridiculous, and frankly ignorant.

Now, that being said, if it doesn't have whatever feature/functionality you're looking for, simply state that it's not ready for your use case as of yet, and if it gets that feature/functionality, you'll take a second look. But to simply declare it DOA is just plain stupid.

It is not ignorant to proclaim Java FX DOA. It is a really cool technology with a lot of perspective, but as long as no mobile runtime is available it is pretty much useless. The focus these days is on mobile applications and on reducing the complexity of developing for multiple platforms at once and in improving productivity. The case for a good platform to do that is stronger than ever with the fragmentation of mobile OSes.
But, SUN does not seem to realize that and does not release a mobile runtime. Therefore, effectively, Java FX is DOA. As I see it the main ignorance is at SUN.

But, SUN does not seem to realize that and does not release a mobile runtime. Therefore, effectively, Java FX is DOA. As I see it the main ignorance is at SUN.

When you say "does not relese", do you mean "has not yet released", or "will not release"..?
The fact is none of the three main VM solutions (AIR, JavaFX or Silverlight) launched across all platforms (desktop, web and mobile) from their first version. JavaFX is on desktop and web aleady across Mac, Windows and Linux; on a limited number of mobile devices and on mobile emulator; and will soon be on Blu-ray and set-top-boxes. This is no worse than its rivals: Silverlight, for example, is still vaporware on the desktop. And neither Silverlight nor AIR have made serious moves (apart from talk) towards TV sets.
It would seem, therefore, by your standard this would make *all* the major platforms DOA.
It's worth noting all this fuss about Flash and RIM (and how it spells the doom of JavaFX) concerns just the web-embedded Flash player, not Adobe AIR. So Blackberry's will be able to play Flash based web pages and games, but they won't be able to run AIR applications installed directly onto the phone (at least that's how I read the press release!) Being able to view Flash content on web oages is not the same as actually installing apps onto the device itself -- effectively Blackberry Flash developers are in the same position as iPhone developers were before the AppStore came along (when all custom apps had to be browser based.)

It is a bit uncertain what is going on and whether a mobile runtime will not (never) be released or will be released in time. The original message was almost a year ago that a mobile runtime would be released within a few weeks but then something changed and we are now almost a year further and there is no telling what will happen.
Also, looking at a recent roadmap from Nokia (http://blogs.forum.nokia.com//data/blogs/resources/300116/SymbianJavaExternalRoadmapOctober2009.pdf),
which goes well into 2011, javafx isn't even mentioned. In contrast, Nokia is spending large sums of money in cooperation with Adobe on Flash and AIR (http://www.mail-archive.com/javaposse at googlegroups dot com/msg02584.html).
In other words, in order for JavaFX to become a success, it is important for a mobile runtime (which is a jar) to be released so that, independently of adoption of JavaFX by vendors, it can still be deployed on their devices.
Looking at current developments, Adobe Flash+AIR is becoming more and more the ubuiquitous platform and JavaFX is losing the battle.

I was working till recently with them and I can tell you that I seen there the most weird and incompetent product management I could imagine - ever. The fact that they adopted some Adobe tech doesn't mean that this was done exclusively as a result of a technical evaluation, all decisions at RIM are taken first from a *political* perspective. They are losing very aggressively on the market and they try to create strong ties with other heavy players for keeping the head out of the water. So, yes, as long as SUN went to Oracle their investment in Java as core platform - at the end, BB OS is a SUN Java clone, is on the shaking grounds. In this case, just the Adobe RIA infrastructure can help them keep the device UI still competitive and backward compatible from a user experience point of view. This will make them attractive from a business perspective as potentially having Adobe joining the cash :-). So, in the context, I would say this was more business strategically decided by RIM as a result of their market situation now.

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.