Skip to main content

Poll Result: Many Have Not Yet Experimented with JavaFX; But Maybe That's OK?

Posted by editor on August 24, 2013 at 12:22 PM PDT

In the most recently completed Java.net poll, a large majority of developers stated that they have not yet done any development using JavaFX. Java.net polls are not scientific, of course, but it's unusual for the polls to produce such a decisive result.

Participation in the poll was high: 2120 votes were cast, and three comments were posted. The exact question and results were:

Have you done any JavaFX development yet?

  • 5% (102 votes) - Yes, I regularly use JavaFX
  • 6% (131 votes) - I've experimented with JavaFX
  • 4% (83 votes) - Not yet, but I plan to try it out soon
  • 85% (1804 votes) - No

So, yes, a decisive result. But, if you think about this, it's actually a pretty positive result with respect to JavaFX adoption. JavaFX is new. Not all that long ago, it could only run on Windows -- which limited its efficacy significantly, since a founding concept behind Java is that you can run your software "anywhere."

Then, consider the need for user interfaces -- what percentage of Java developers work on the user interface side of things? My guess is that it's a much smaller percent than the number of developers who work on the enterprise side.

So, if 5% say that they regularly use JavaFX at this point in the technology's lifespan, that's perhaps not all that bad. Managers will think long and hard before they decide to invest the time, effort, and money to replace well-tested existing UI software built in Swing (for example) with a new JavaFX UI.

As for developer interest in JavaFX, a combined 10% said they've either experimented with JavaFX, or they plan to do so soon. All in all, I'd say this bodes well for JavaFX.

The comments were both interesting and informative. For example, branded_rhombus pointed out that JavaFX still isn't entirely up to snuff in terms of Java's "write once, run anywhere" mantra:

Our desktop applications are written in Swing as we support Solaris as a platform. Unfortunately it appears that JavaFX will never support Solaris.

MichaelGrimm noted another area where JavaFX is not yet a universally usable platform:

Lack of support for languages written from right to left excludes the use of JavaFX. I have to use Swing until this bug gets fixed.

Meanwhile, pjmlp stated:

Our consulting projects have moved back to Qt/C++ on the desktop for multiplatform, and for Windows only projects, WPF. Not sure if JavaFX is not arriving too late...

So, while JavaFX has progressed significantly in recent years, there is still some incompleteness that bars some developers and projects from utilizing it.

New poll:

Our new poll looks ahead to JavaOne 2013, asking you to respond to the statement: The most important track at JavaOne 2013 will be... Voting will be open until Friday, September 6.


Subscriptions and Archives: You can subscribe to this blog using the java.net Editor's Blog Feed. You can also subscribe to the Java Today RSS feed and the java.net blogs feed.

-- Kevin Farnham (@kevin_farnham)

Related Topics >>

Comments

No, it is not OK !! You are in denial !! Look how JavaFX's ...

No, it is not OK !! You are in denial !! Look how JavaFX's main competition is doing

I think you're right about the lack of Java-based ...

I think you're right about the lack of Java-based thick-client developers. I've done surveys in my user group and I've seen about 5% or so doing thick client development.

Also, since JavaFX is only released on desktops right now and there is a bit of a learning curve, the existing thick client developers maybe staying with Swing. Once JavaFX becomes viable for Android and iOS, that will provide a big impetus to migrate since it is painful to write native applications on multiple types of mobile devices now. (The Tower of Babel problem.)

Also, many of the existing web applications are basically nearly static forms and for whatever reason, desktop users seem to be happy with clunky web applications whereas mobile users seem to prefer native applications. (See story about FaceBook dumping HTML5 for native applications.)

I also think that eventually the technical debt involved with writing large (50K-100K line) Javascript-based (non-type-safe) applications will become so huge that there may be a revival in Java based client applications to reduce maintenance costs, as well as, the desire for better performance and richer, less restrictive technical capabilities.

If people think Java is dead on the Desktop, check out Minecraft! :-)

Or check out hundreds of others ...

Or check out hundreds of others here:

https://platform.netbeans.org/screenshots.html

"JavaFX is new." It's not that new. It has been in ...

"JavaFX is new."

It's not that new. It has been in development since 2007.

"...what percentage of Java developers work on the user interface side of things? My guess is that it's a much smaller percent than the number of developers who work on the enterprise side."

I tend to agree with you, though I don't think that it is necessarily by choice. If client-side Java options were more compelling, that number might be a lot higher.

I would personally love to see a modern Java UI toolkit that uses native widgets (basically a next-gen AWT or SWT). I'd want it to support both desktop and mobile, though not necessarily transparently. I'd be fine using one set of widgets for mobile and another for desktop as long as my common code could be written in Java.

True on the newness point. JavaFX has been in development ...

True on the newness point. JavaFX has been in development for quite a while, but the ability to utilize it on OS's other than Windows is relatively new. Absent that capability, JavaFX couldn't really be a viable element within the Java UI stack.

Regarding client-side Java, it seems like the evolution of hardware (including phones, tablets etc.) has occurred at such a fast pace as to make it difficult for a software framework that attempts to address all the hardware options to keep up.

The fact that there are so many cases where Java is used for the back end, and an entirely non-Java solution is utilized for the client side, backs up your point about the number of Java developers who work on the client side. This is ironic, from my point of view, since early on Java applets were a prominent aspect of the extension of the early World Wide Web into complex interaction between end users and server side applications.

Thanks for the thoughtful commentary!