Saturday, July 24, 2010

How Much Time to Spend on JavaFX at JavaOne 2010?

For any conference that one attends, one of the difficult decisions is which presentations to attend.  This is particularly problematic when there are some really interesting-sounding presentations held during the same hour.  I find that I often change my plans for which presentations to see based on earlier presentations in the same conference.  A presentation (often an opening keynote) may stir my interest in a topic I had entered the conference not knowing or not caring much about.  On the other hand, an early presentation could equally dissuade me from attending further presentations on the same topic because I may realize that the subject is not as relevant to me as I thought it would be.

I am already struggling with this for JavaOne 2010, particularly when it comes to JavaFX presentations.  On the one hand, there are some abstracts for JavaFX-related presentations that look interesting.  On the other, I am still a little bitter about my time wasted looking into JavaFX after 2007 JavaOne and 2008 JavaOne.  I realize that I can only blame myself for any wasted time on a third failed attempt at learning to love JavaFX.  JavaOne 2010 gives me the opportunity to learn more about JavaFX in a potentially optimized way, reducing the risk of time wasted.  That being said, I could end up pretty disappointed if I miss some really good presentations to attend JavaFX presentations and then realize either during the conference or (even worse) realize later that JavaFX does not have a future.

This isn't to say that I wouldn't attend a presentation on something I don't know a lot about, because I would.  I feel that one of the best things about attending a conference is the ability in an hour or two to quickly identify whether something is worth further effort.  JavaFX, though, is different because I've already been burned by what I believe was hyperbole.  It's one thing to spend an hour in a session learning about something and realizing it has no immediate benefit for me.  That's actually positive because I only needed to spend an hour to learn that.  For JavaFX, I already have incurred a large tab for the time spent learning about it with little satisfaction.  There has been a huge net opportunity cost associated with time spent with JavaFX so far.

Max Katz, in his blog post JavaFX... does it have a future? (Sys-Con Media version), provides significant additional information for me to consider as I try to resolve the dilemma of deciding how much time to spend on JavaFX at JavaOne.  It is obvious from the tone and content of the writing in this post that Katz is an advocate of JavaFX.  Perhaps even more significantly in terms of considering JavaFX presentations to attend at JavaOne 2010, Katz is presenting at JavaOne 2010 on Enterprise JavaFX Applications with CDI (JSR299).  With all of this in mind, I found some quotes in this blog post particularly interesting.  I look at some of them in detail here in the context of trying to determine what number of JavaFX presentations to attend and which ones to attend.

First off, I appreciate that Katz is a realistic.  Some evangelists for a particular technology can see no wrong (or at least not admit any wrong) with their favorite technology.  This is, of course, ridiculous because nothing is perfect, everything has its flaws, everything has problems it fits better than others, and the natural difference of human beings' opinions means that nothing will ever be "perfect" for everyone.  In my opinion, this early quote from Katz's blog post provides him some credibility:
Don’t get me wrong, JavaFX is very far from perfect. It has it’s problems and challenges (listed below) and its future is hanging on life support right now.
I believe my previous blog posts on JavaFX prove that I am in agreement here.  This is precisely why it's difficult for me to justify time spent on JavaFX (including in JavaOne presentations): I just cannot be sure that it's going to be around (at least in a form acceptable to me) for more than the near-term future.

Katz lists several benefits (the good) of JavaFX (such as "power" and "ease of use") first and states:
I have been working with JSF (JavaServer Faces) since its inception and I can tell you that using JavaFX Script to build the UI is probably simpler than using JSF.
I have no doubt that this is true, but unfortunately being simpler than JavaServer Faces is the purview of just about every Java-based framework out there and non-Java Flex/ActionScript is, in my opinion, significantly less complicated than JSF.

Katz fairly addresses one of JavaFX's best known problems (the bad): deployment issues. He covers this pretty thoroughly and says exactly what needs to be done to remedy this: "Make it as simple and transparent as running a Flash application."  Well said.

I agree with Katz when he states that developers today need to learn new things all the time, so learning JavaFX Script as a new language should not be a big deal.  As long as everyone understands it is a new language, I think this is a fair statement.  My problem has been when anyone has pushed JavaFX as "Java."  You cannot have it both ways.  Is it Java or is it something else?  It may be Java in the same sense that JRuby and Groovy are Java, but Groovy is significantly more Java-like in syntax than is JavaFX Script.  Because it's not Java in terms of syntax and because there's no JSR (that I'm aware of) for it, its last hold on "being Java" seems to be the ability to run in the JVM, but every language and its brother seems to be doing that these days.

Katz makes several good points that I am skipping here (but I recommend reading his entire blog post if you have any interest in JavaFX whatsoever).  His conclusion, I believe, is objective and spot-on:
There is still time to make JavaFX successful, but the time is running out. First, fix the deployment issue as soon as possible.  ...  Second, Oracle needs to make it very clear what its plans are for JavaFX (maybe at JavaOne 2010?).  ...  I think Oracle has 6-12 months at the most to try and revive JavaFX. If nothing happens by then (which would be about 4 years since the technology was announced), we just might as well close the door on JavaFX. 
There's nothing I can add to that.  Probably the only debatable piece is the timeframe he provides of 6  to 12 months.  It might be longer (say 18 months), but it could be that Katz is right on.  With the seemingly increasing negative news regarding JavaFX and the strengthening of its competitors' positions, I do think there is a limited window for Oracle to turn things around for JavaFX in terms of it ever being mainstream popular.  There's always a possibility that it's already too late.

Katz's blog post increased my interest in attending his JavaOne 2010 presentation.  The two main reasons that I might not attend it are that there are several really good presentations of high level of interest to me and his topic is not really focused as much on the introduction to and examination of the future of JavaFX as I probably need and want.  Katz's presentation is scheduled for Monday, September 20, at 1 pm, at Golden Gate 2 in the Hilton San Francisco.  I currently have "Advanced Java API for RESTful Web Services (JAX-RS)" scheduled for that slot.  It's still a difficult dilemma because I am now really interested in Katz's presentation, but I think it's safer to bet my time and attention of JAX-RS and REST than it is on to bet them on JavaFX.  I am fairly confident what I learn from a JAX-RS/REST presentation will be of benefit for some time to come.

I hope that JavaOne 2010 provide some direction that allows us to be comfortable knowing how much time and effort to invest in it.  If I have a better idea of what JavaFX is going to become, then I can better make the decision about how much time to invest in JavaFX and what projects to build around it.

1 comment:

Sergey Surikov said...

Make it as simple and transparent as running a Flash application.
--

Katz are wrong. You can't compare JavaFX and Adobe Flex. You should compare JavaFX with Adobe AIR (see http://www.adobe.com/products/air/ ).
Adobe Integration Runtime works like JavaFX + Webstart. AIR has same problems with deploynment like JavaFX. But AIR works well.