I've been a zone leader with DZone since 2008, and I'm crazy about community. Every day I get to work with the best that JavaScript, HTML5, Android and iOS has to offer, creating apps that truly make at difference, as principal front-end architect at Avego. James is a DZone Zone Leader and has posted 639 posts at DZone. You can read more from them at their website. View Full User Profile

When Will JavaFX Get Real Community Acceptance?

01.08.2010
| 7269 views |
  • submit to reddit

Even though we're two years on from the 1.0 release of JavaFX, 2010 could be the defining year for the technology.  With the mobile device space really taking off, JavaFX has to prove that it deserves to be up there with competing technologies. While some say that it is all too little, too late, I think that JavaFX has one key feature that gives it a fighting chance - an application you write for JavaFX mobile can also work on the web or desktop. 

Earlier this week, I asked JavaLobby readers what they would develop their mobile applications with. So far, the overwhelming majority, at about 70% say they would use Android. JavaFX comes in second at just 16%. Despite the low number, I don't think all is lost but I wonder what JavaFX has to do to get buy in from the Java community.

Sun have been actively looking for feedback from JavaFX developers to find out what they want, it's a good start and has some interesting results. The most popular profile is the desktop, followed by the web. Maybe mobile is less popular as it was released later, but with so few interested in deploying their apps using JavaFX for TV, is it worth releasing that profile at all? 

The most important question in the survey asks the developers to rate features for future releases of JavaFX. It's not surprising that top of the list is to get more controls in, and that developers want better tooling. It looks like tooling is already addressed with the newly available JavaFX Composer preview in Netbeans. 

I'm really looking forward to see how JavaFX progresses this year. We should be seeing JavaFX 1.3, which sounds like it will address some of the concerns around the UI controls. This slide from a presentation at Devoox shows (in asterixs) what new controls will be added: 

With the key developer concerns covered, I hope that the investment that has been put into JavaFX pays off for Sun this year. For those who aren't using JavaFX, what would it need to have to make you change your mind? And to those who are using it, what do you feel is missing?

 

Comments

Thierry Milard replied on Fri, 2010/01/08 - 4:49am

I also see javaFx could finally be a good future for us.

Personnally I feel javaFx language is good.

Now there are still two weak sides but they are BIG compapring to Android (mobile) and/or Flash (Internet).

In english I think we say "There are two stepping stones missing yet" :

1) PC : An as-quick-as-flash java j2se startup

2) Mobil : Well ... some Phone using javaFx.

 

I also 2 questions regarding Sun's strategy on the mobil business. For the mobil world we can all see that it is becoming a 2 top-players :

Androids phones Vs Iphone

Androids :The first massive acceptance on the manufacturer sides came 2 years ago when they decided to "open source" the code of Android. At the time the gui from Android was not so good looking. I feel Google made an good early adopter "Open source ATTACK stategy". It was a turning point to convince manufacturers.

My questions concering javaFx are simple. 

a) Wouldn't it help to convice hardware manufacturer to also open source javaFx platform (now that it is a fairly good one)  ?

b) Couldn't javaFx benefits also from an attacking open source trategy (ie. open source as soon as the market is growing and invest) then a defensive one (ie. Open source when the battle seems lost and cut cost ) ?


Voila.

In overall I wish Sun a offensive and succefull 2010 !

The aventure is back at Sun ! This is great.

Armin Ehrenreich replied on Fri, 2010/01/08 - 6:16am

APIs for Java are needed. The JavaFX functionality should be accessible from the Java platform, that means from Java, Groovy, Scala... I hate it, to be forced to use a yet another language for the GUI portion of a desktop application. It is a nice language and who wants, should use it. But Sun please understand, most people don't really need a freaking new declarative scripting language. There are already far too many scripting languages around.

JavaFX functionality should be easily integrated in Swing and therefore in the Netbeans application platform. It should be possible to create professional looking applications and use some of the the cool new features such as HTML rendering, PDF display, media playback and so on. For professional GUIs I do not want to have a complete Flash-like interface as in the JavaFX Script applications I have seen so far.

Forget about interactive TV. TV is a totally passive medium. People switch their brain off when looking at a TV screen and let things happen, but do not want to make decisions.

ff aaa replied on Fri, 2010/01/08 - 6:23am

IMHO, JavaFx has potential. With 1.3, Language and development for 2D graphical applications is superior to others (ActionScript, Silverlight stuff and Android api.) Those are my takes - A very trimmed down JRE. just JVM, core libs and Java2D. - Android support. - Easy deployment - browser interaction is key. Make it talk to the web page naturally too. - Dont focus on 3D or physics yet, they are distractions. - Less Resource usage and more performance. - Make it real open source. no GPL please. give it to Nokia, Apple and Google under a non restrictive licenses. Apple will not accept but hey

Casper Bang replied on Fri, 2010/01/08 - 6:52am

I have a hard time seeing JavaFX going anywhere, and would generally be much more excited if it was not this isolated applet/webstart technolgy but rather a full replacement for Java. The language is interesting and succinct, but it has to compete with stacks and languages already accepted. So for me the only thing that would breathe some life into it, would be if it could be used on Android.

Olivier Allouch replied on Fri, 2010/01/08 - 7:18am in response to: Armin Ehrenreich

@Armin: I can't agree more. The Java API is mandatory. We can't just jump to both a new technology and a new language, even if both are simple. JavaFX has to get inside our programs slowly. We can start by using the new controls in Java.
"Let's replace that header panel by some fancy JavaFX."
"Let's replace that other panel, but this time using JavaFX Script".

It may seem strange, but I can assure you that if you want us to use JavaFX Script, you have to first give us the Java API.

Olivier Allouch

Osvaldo Doederlein replied on Fri, 2010/01/08 - 8:22am

As usual in 99% of the articles about "will JavaFX survive?", I have do make this correction: it's not two years old (as of jan-2010); v1.0 was released in dec-08 so that's just 13 months old. It's kinda wrong and unfair to round that up to "2 years". Yes, Sun has been hyping FX much longer than that, I think since JavaOne 2006, but that was a gross mistake. Yes, early-access releases were made available a few months before dec-08 but these were really early; v1.0 had massive fixes and breaking changes even compared to the latest preview release. Even that v1.0 is now widely considered to be just "developer release", it didn't have enough functionality or quality for any real-world deployment; but even not considering this, JavaFX is just one year old (plus one month). JavaFX Mobile is much more recent, the FCS release shipped less than 2 months ago and still just for WinMob. JavaFX TV has yet to ship. The design tools have yet to ship (the NetBeans FX Composer is in beta - I'd expect the FCS to come in 1-2 months, perhaps in some NB 6.8.1 update, perhaps paired with the FX 1.3 release). The JavaStore, that is a big part in Sun's plan to promote and also monetize on FX (plus all other client-side investment like JDK 6u10+), has yet to hit FCS status and quality (I guess this depends from JDK 6u18 and FX 1.3). The Design Tool has yet to be released publicly even in EA form, all we get is a continuous stream of presentations in conferences.

In summary, it's come a long way - and very quickly - in these 13 months since 1.0, but there are still important missing pieces. The next 6 months will be extremely critical for FX's sucess; in this timeframe we will see:

a) JDK 6u18 (end jan / early feb) with more work in plugin, JAWS, core AWT/2D support, deployment, startup etc. (as well as general performance - like HotSpot v16 backported from JDK7)

b) The FX 1.3 release (late feb), with tons of important stuff (compiled bind, many new controls although not every one we want) and hopefully more Mobile ports (MWC happens in mid-feb)

c) FX Composer FCS; Design Tool at least beta/R. (Now the missing piece will be a decent (free) visual editor for Eclipse; the market advantage of Eclipse is a great barrier even if the tools Sun is providing will totally rock)

d) Early JavaFX TV

e) The JavaStore really finished and open worldwide. If all items above are well delivered, I see no reason why the Store can't make decent success. Notice that (different from the Mobile market), in the desktop Sun is not catching up - I don't see any app store from Adobe or Microsoft in my Windows desktop, not yet.

f) Finalization of the Oracle/Sun buyout, so everyone gets to know which Sun projects and products Oracle is really pushing forward (and not just put in life support for a few years, if not kill immediately). (I've just seen a FX guy tweeting announcements of open positions - apparently for experts in Saffron and other font engines - so the may know something we don't; people surely don't hire more engineers this week if the project may be closed next week after the EU finally clears the deal and Oracle starts rolling the dice).

Jacek Furmankiewicz replied on Fri, 2010/01/08 - 8:57am

We've been over this so many times. No one wanted JavaFX, we just wanted a better Java.

6 months of hardcore work on core Java and whatever language features are in JavaFX could have been in core Java instead. Add a nice Scenegraph Java API on top of that and we would have been done.

However, Sun unfortunately misread this basic need and decided to try to push a totally new language. And now it's suffering the consequences and acting surprised that Java developers are not jumping into JavaFX en masse.

Well, obviously not. And I don't see it happening any time soon either.

 P.S. Not to mention that after having worked with jQuery recently I think most of us will be picking up jQuery and Javascript much faster than JavaFX. Browser technology and libraries for RIA have come a long way and we Java devs need to get over our Javascript aversion.

Osvaldo Doederlein replied on Fri, 2010/01/08 - 10:26am in response to: Jacek Furmankiewicz

No one "wanted" Flash or Silverlight (that also contain new languages, XML-based DSLs, runtimes etc.), either. Now it's possible that Sun doesn't have what it takes to compete with Adobe and MS, but that's another story. Users (i.e. developers) never "want" stuff that doesn't still exist. Innovation never comes without risk; some people will always complain that the same features could be delivered as simple libraries or perhaps incremental changes to existing languages/frameworks.

Don't underestimate the difficulty to extend a system that's as successful and mature as the Java language and its core APIs (including AWT/Java2D/Swing). I suggest you to track the whole discussion over JDK 7 lambdas (lambda-dev and closures-dev lists), and that's a single language feature- although a very important one, but something that's considered almost trivial in languages that were designed with that stuff since v1.0. But not in Java; we still risk having no closures at all in Java 7, or perhaps a half-baked design with lots of excuses (backwards compatibility yadda yadda difficulty for average programmers yadda yadda migration of legacy APIs yadda yadda...). Now, you will see that JavaFX Script contains not one, but many language innovations - BTW it does support closures, but that feature barely catches people's attention, in the shadow of less-trivial stuff like powerful properties, binding, sequences, object trees and other declarative aspects, trait-based OO model etc. The chance of having all these goodies in a reasonably backwards-compatible, Java-derived language - and decently implemented wrt features, good syntax, orthogonal behavior with existing language features etc. - is zero.

P.S.: One bright point of JavaFX for me is that I don't have to use a JavaScript[-derived] language. Or to "program" in XML. Call me a static-typing/class-model bigot, but I will work all day long with those languages to build real-world complex software, the day I start smoking crack and lose 90% of my brain cells. To each his own; IMHO, JavaFX Script has lots of appeal, enough to bring back to the client-side some hackers who have spent the last decade writing only back-end stuff, in disgust with the load of duck-typed spaghetti that is JavaScript, HTML, etc. (Yet I want the standards-based, HTML5 web to succeed big time, too... but I'll let other people write the code. Or use something like GWT or RAP.)

Jacek Furmankiewicz replied on Fri, 2010/01/08 - 11:18am in response to: Osvaldo Doederlein

Well, after having completed a portal recently witha jQuery UI frontend and a JAX-RS Java backend, I don't see the need for GWT or RAP at all.

Really, getting data in JSON from a Java REST backend via jQuery's REST support is so trivial (and it even preserves the full Java object graph, thanks to JAXB) that I don't understand why anyone thinks GWT is needed.
Development time is super-fast (no restarts for client-side code) that I don't see why one would want to suffer from the overhead of GWT's Java->Javascript compilation (which I hear is brutal).

 Not to mention the jQuery ecosystem (plugins, developers, books, etc.) is huge and dwarfs any RIA (Flex, Silverlight, not to mention JavaFX).

Truly, Javascript in 2010 via jQuery is not painful at all. It's actually not such a bad language.
And it's a very marketable skill, far more than JavaFX if I dare say.

Rogerio Liesenfeld replied on Fri, 2010/01/08 - 11:23am

IMO, we won't ever see a (significantly) "better Java". Face it, the Java language and standard libraries are too widely used to be messed with at this point. Also, as Osvaldo said, from a language design point of view it's not easy to add radically different features to an already mature language.

For me, the future on the JVM is JavaFX. A whole new language (which is NOT a "scripting" language) and a whole new set of standard libraries; at last, we will have a replacement for AWT and Swing.

As an OO & Functional language, I consider JavaFX Script more well designed than Groovy or Scala. Anyway, given that those other two don't really add much in the way of new APIs, I doubt they really stand a chance to become mainstream.

We will have to wait and see...

Rogerio Liesenfeld replied on Fri, 2010/01/08 - 11:34am in response to: Jacek Furmankiewicz

I can see you haven't really used GWT. The Java->JavaScript compilation is costly, but a developer shouldn't be doing it all the time; during development, the "hosted mode" browser (which does not involve JavaScript code generation) is what gets used most of the time.

For a team of Java developers creating a large web-based UI, it makes no sense to use JavaScript libraries like jQuery. From my experience (think a web app with 200+ GWT modules), it's much more productive to use GWT, which allows all of the application code to be developed in the same language (Java), with the same tools (Eclipse, IDEA, NetBeans), by the same people (Java programmers, which can work both on server-side code as well as on client-side code, without switching tools).

Jacek Furmankiewicz replied on Fri, 2010/01/08 - 11:42am in response to: Rogerio Liesenfeld

Ah, good point. I stand corrected. Thanks for enlightening me on this topic.

I still like the jQuery ecosystem (insane amount of plugins you can use without having to wrap them in any way), but for large apps you are correct.

Either way, I'd still much faster choose jQuery or GWT over JavaFX (going back to the original discussion) :-)

Max Katz replied on Fri, 2010/01/08 - 12:48pm

Tooling. In addition to NetBeans, we (Exadel) have been working on JavaFX plug-in for Eclipse. Current version is 1.2. We have started work on visual designer as well. For enterprise, we have Flamingo that allows to connect JavaFX to enterprise back-end such as Seam, Spring and Java EE.

Max
http://mkblog.exadel.com

Rogerio Liesenfeld replied on Fri, 2010/01/08 - 1:48pm in response to: Jacek Furmankiewicz

Yes, for a new business web app GWT is a better choice today, as even JavaFX 1.3 won't be complete/mature enough.

On the other hand, JavaFX really takes UIs to a whole new level of "richness". The stuff (effects, animations, transitions) described in the excellent Filthy Rich Clients book is considerably easier to do with JavaFX than with Swing or with GWT/GWTCanvas.
I believe these new RIA tools (JavaFX, Silverlight, Flex), as well as browsers supporting HTML 5 + CSS 3 (see this article, for example) will change the way UIs for typical applications are developed. This is one of the reasons that will make the "old" JDK less and less attractive for new projects.

Armin Ehrenreich replied on Fri, 2010/01/08 - 3:18pm in response to: Rogerio Liesenfeld

I also thought from the first moment I read more deeply about JavaFX that it is an improved Java language. So please Sun, don't call it "scripting language" and "for designers". But nevertheless the functionality of the JavaFX platform should be accessible from the other languages. That is a main design principle of the Java platform. And maybe Sun is wrong (as so often) and people want to stay with classic Java in the foreseeable future as most people do not regard it as bad as it is often blogged by a tiny minority. Or Scala gets more accepted, or Fan or... let the developers decide.

An important point for the Java platform is that JavaFX functionality should be integrated in Swing. It would take a long time and much money until you could do as good GUI applications in JavaFX as you can do in Swing and the Netbeans platform today. And there is no sense in replicating this functionality and throwing away all the expertise. Swing is a very good and mature GUI-Toolkit. You may use a Flash like interface for a mp3 player or the jokes from the JavaFX demo site, but not for complex GUI applications that integrate in their platform.

Currently the situation is as worse as it could be. No one knows what will come and when. And you can not take any advantage from all this JavaFX work from the standard Java platform. I could use a JWebPane displaying "street HTML" that can be integrated in my Swing apps very well. Or a PdfPane. Please Sun/Oracle make this happen.

Otengi Miloskov replied on Fri, 2010/01/08 - 5:10pm

It could be possible that JavaFX is the next big thing and not Scala or Clojure?.

Im a Flex fan, I sit down to discuss with my team for a new project, we brainstormed and I decided to use Flex because it is the one I had experience but my team have not experience before with eather Flex or JavaFX at the end we decide to use JavaFX because they told me JavaFX is more intuitive the syntax and the language, it have performance and it can reuse Java Libs or integrate with Java tech more easily. I was dissapointed at that time but I gave a shot with JavaFX, It was a great experience, I think JavaFX have a lot of potentional.

I will not touch Silverlight, Anything come from M$ ruins me as always.

Also Oracle will put lots of cash to JavaFX so I think JavaFX have a nice future. HTML5 or Ajax(Jquery or GWT) It is also very nice and I want it also succed but as Rogerio said JavaFX brings more richness in graphics and animations and thats what the end users wants the eyecandy. Why IPhone is popular because the eyecandy that sells it is marketting almost sells by their self and that JavaFX have.

So I hope Java7 gets closures but also I think JavaFX will begin to have a success and more with the next release 1.3

Andres Almiray replied on Mon, 2010/01/11 - 1:10pm in response to: Rogerio Liesenfeld

"As an OO & Functional language, I consider JavaFX Script more well designed than Groovy or Scala."

JavaFX Script is a blatant copy of Ruby and Scala (at the syntax level, not the libraries). This was very clear back on the earlier days (when F3 became JavaFX Script and it was still interpreted) as the language was very close to Ruby with a dash of JavaScript. Then came versions 1.1 and 1.2 and JavaFx became a pale copy of Scala.

I can hardly consider JavaFx better designed than the other two languages. There are no improvements on data structures (like Clojure does), there are plenty of gotchas (flat sequences, string concatenation, mixing with other langs) which can trip you from time to time until you learn the rule. Granted Groovy and Scala also have their gotchas, but I've found it to be easier to get a responsefrom their respective communities (and much faster too) YMMV.

Rogerio Liesenfeld replied on Mon, 2010/01/11 - 4:26pm in response to: Andres Almiray

Well, I looked at code written with Scala, Groovy, and JavaFX Script and to me the JavaFX code looks more elegant.

One such example can be found here, with Scala, Groovy and JavaFX Script versions of the same small GUI program.

Andres Almiray replied on Mon, 2010/01/11 - 7:56pm in response to: Rogerio Liesenfeld

aha! so it "looks more elegant", but is it actually? Have you tried to build an enterprise application in the three languages? Have you actually come across the need for currying (groovy) and partial functions (scala) that javafx does not have? Have you experienced the usefulness of Scala's traits (much more advanced than JavaFx mixins) or the compile/runtime mixins offered by Groovy?

The thing is, JavaFX Script is a niche language, tailored for UI needs while the other two are general programming languages. They surely could do a better job supporting bindings and animations in terms of UI but believe, you'll never dream of building a server side nor a webapp with JavaFX, you simply can't! it was not designed for it. So whatever OO/FP capabilities JavaFX Script exposes are somewhat limited to the ones Scala and Groovy expose given that their domain is wider.

Of course I must accept I'm biased towards Groovy, still here are a few more Groovy/JavaFX code comparisons

http://jroller.com/aalmiray/entry/griffon_gfxbuilder_fxbuilder_side_by
http://jroller.com/aalmiray/entry/fxbuilder_update_3
http://jroller.com/aalmiray/entry/another_look_at_fxbuilder_griffon
http://jroller.com/aalmiray/entry/swing_pop_quiz

I'll bet the Scala version of some of those examples (using the scala-swing library) is not that different.

 

Rogerio Liesenfeld replied on Tue, 2010/01/12 - 9:02am in response to: Andres Almiray

For an enterprise app I would still use Java (with GWT on the client side).
For a rich desktop app, though, JavaFX seems a much, much better option. It's what it was created for in the first place, after all (between other things, such as rich mobile UIs).
I have not yet really started using JavaFX, as I am waiting for the new UI controls in JavaFX 1.3.

Now, I bet the "bind" keyword and "on replace" triggers in JavaFX Script are more useful language features than currying or partial functions. Also, JavaFX Script is a younger language, not yet fully developed. It doesn't yet include generics, annotations, enums, or direct support for maps, but these (and more) will eventually be added. So, I agree that right now Groovy and Scala are more complete languages. I just don't believe they have a great future (time will tell...).

I have looked at Griffon. It's nice, but in the end it's only a wrapper on top of Swing and Java2D. The JavaFX GUI APIs, on the other hand, are completely new technology which uses a different rendering model: "retained mode", while Java2D is "immediate mode" only.

Coffee Jolts replied on Thu, 2010/01/28 - 11:08am

In order for me to use JavaFX in a real project, it needs to be performant. It needs to be able to do simple animation without tearing and stuttering. It needs to be able to play video without pegging the cpu. Sun keeps heaping more and more UI goodies on top of a graphics stack that is sorely lacking. Fix the foundation before you put additions on the house, Sun.

Rogerio Liesenfeld replied on Wed, 2010/02/03 - 8:38am in response to: Andres Almiray

Just for the record, it seems JavaFX Script actually supports currying and partial functions (I am not 100% sure at this point, though). The "Pro Java FX Platform" book has a relevant example in page 181, although the word "currying" is not mentioned.

Rogerio Liesenfeld replied on Wed, 2010/02/03 - 8:48am in response to: Coffee Jolts

Isn't JavaFX 1.2.1 already doing that? The JavaFX team is also working on a brand new graphics engine called Prism, which is expected to be released with or after JavaFX 1.3.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.