Data Intensive vs Graphic Intensive Applications

Charles Ditzel recently made an interesting point (here):

"I think this year was the year of RIAs with the arrival of JavaFX, Flex/Flash and SilverLight. I think it has dawned on a lot of developers that RIAs are limiting. In my mind, they seem designed for graphic intensive web apps - but most enterprise apps are data intensive. Unfortunately I don't see JavaFX going anywhere until they fix it so that it can seamlessly support for bi-directional interoperability and RCP interoperability is built into it. I'm not saying that there won't be a lot of RIAs out there - just that they seem relegated to flashy, low-data graphics apps on web sites."

What I like about this (in addition to the predicted increase in popularity indicated above) is the distinction made between graphic intensive and data intensive applications. That distinction explains (to me) a lot of the confused discussion re JavaFX vs NetBeans Platform. These statements (made by opposite camps) are typical implementations of that confusion:

  • "Swing is just too hard and not Flash-like enough. Developers want to be able to create UIs very quickly (with complex animations done in a declarative style, etc) and they want to create them for multiple targets (i.e., desktop, web, mobile, i.e., 'all the screens of your life')."

  • "JavaFX is just not good enough. It just focuses on the UI and, even there, is mainly focused on animations and other similar Flash-like stuff. It doesn't offer enough for me to move to it, the switch to JavaFX from Swing simply doesn't offer me enough incentive, and the pay off is pretty weak for my purposes. Plus, I don't care for 'all the screens of my life', since I'm doing a lot of processing and displaying large amounts of data, sometimes while in a car or in the middle of a field or on an oil rig, so that the whole web story is meaningless to me, except as an alternative/addition to my main application which is on the desktop."

The first statement is made by a developer interested in creating graphic-intensive applications. For these developers, JavaFX is great. However, for data-intensive needs, the second statement is familiar. Why would you switch to JavaFX if you're creating some large banking application, for example? You're not all that interested in the UI, in that case, sure, you want good and solid UI, it's got to be clear and transparent to the user. However, the stuff offered by JavaFX simply isn't useful enough for moving to it. The modularity of the NetBeans Platform (which means you have to use Swing) is far more important to enterprise applications than the cool UI-story that JavaFX offers.

Ideally, of course, you'd use both JavaFX and the NetBeans Platform. But that's another story. The point of this blog entry is simply to argue that both statements "JavaFX is wonderful" and "JavaFX isn't all that useful" are true, depending on what your application's main focus is: graphics or data.


Good observation, couldn't agree more.

Posted by Ben Hill on January 13, 2010 at 03:30 AM PST #

It is a good observation, but, I don't understand what is so hard about Swing??? I think that Swing is one of the easiest UI toolkits on the market, so the argument that Swing is to hard so lets use JavaFX, does not hold water in my opinion.

Posted by adam on January 13, 2010 at 09:38 AM PST #

About "an another story": Do you know about any (attempts to) mash up Netbeans RCP and JavaFX?

Posted by Adam Skalny on January 13, 2010 at 02:59 PM PST #

I believe that JavaFX represent only a UI layer for enterprise applications. There are too many restrictions in the language, which currently does not allow easy development of business logic (i.e. single threading in EventDispatcher). Perhaps JavaFX will become what is Java Server Faces for Enterprise Web Applications. A view declaration language for RCP applications.

br, josh.

Posted by Aljoscha Rittner on January 13, 2010 at 04:50 PM PST #

I understand the arguments quite well - in the sense that certain things that can achieved with JavaFX are not quite easy to be tackled with Swing. That concernes everything that is related with animation. Since the Swing toolkit does not include a "pre-build" animation facility that may be used out-of-the-box, as a developer you need some understanding how to realize animation on you own. By now, I know how to do it. I've done it with other toolkits too, like the VCL of Delphi. Swing is not more complicated, in fact it is quite easy in many respects. Nevertheless, you end up with the initial question: "What do you \*really\* want to do - a presentation app or a data app", since Swing and JavaFX are definitly targeted on different goals.
On the other hand it must be said: Many features of JavaFX (animation, easy integration of images, ...) would be a \*great\* enhancement also for data-intensive apps, last but not least because more and more users get used to the "eye candy" - and demand it, also for business apps. So, in my opinion, Sun would do a great favour to the Swing plattform as a plattform for data intensive apps and business apps in general, if integration JavaFX into Swing apps would become more easy. That would give Java as a whole a great boost.

Posted by R. Rohm on January 13, 2010 at 04:53 PM PST #

I too don't understand what's so difficult about Swing. Coding GUIs by hand may not be to everyone's taste (mine neither), but Swing doesn't force you to code by hand because the Netbeans graphical editor is more than capable of producing good quality efficient Swing code. Those who want to design their GUI in a declarative way simply need to use the Netbeans graphical editor together with the properties dialog.

Posted by Keith G on January 13, 2010 at 05:25 PM PST #

The inclusion of a charting library in JavaFX indicates that JavaFX is not totally ignorant, when it comes to supporting the needs of enterprises. However supporting charts without supporting databases is just plain stupid. Somehow I cannot find an excuse for JavaFX being completely void of any helpful functionality for the database layer. Otherwise I would consider ditching Groovy for JavaFX. javafx.sql.\*, where art thou ?

Posted by Georg on January 14, 2010 at 05:01 AM PST #

I also thinke that it would help to migrate Swing to javaFx if we could "inside java-swing code add javaFx components.
But I do think opposite of you.
for Visual things, I think javaFx is really coll and plane simple.

If only we could target Android phones ..... or other smart phones.
Just hope in 2010 Oracle guys succed in doing this.

Posted by Thierry on February 07, 2010 at 12:27 AM PST #

Post a Comment:
  • HTML Syntax: NOT allowed

Geertjan Wielenga (@geertjanw) is a Principal Product Manager in the Oracle Developer Tools group living & working in Amsterdam. He is a Java technology enthusiast, evangelist, trainer, speaker, and writer. He blogs here daily.

The focus of this blog is mostly on NetBeans (a development tool primarily for Java programmers), with an occasional reference to NetBeans, and sometimes diverging to topics relating to NetBeans. And then there are days when NetBeans is mentioned, just for a change.


« July 2016