Skip to main content

Is the Swing Application Framework necessary now?

Posted by joconner on March 3, 2009 at 12:45 PM PST

OK, I'll bite, and I'll ask the question. Although resurrecting the Swing Application Framework (SAF) is a noble and respectable goal, is that even necessary now with JavaFX? If Sun does finalize and fix any remaining rough spots in SAF, is any significant number of developers going to benefit?

Even though I mean no harm or disrespect, someone is bound to view my question as an attack. It's not. I thought the Swing Application Framework was a great idea. I even spent time writing about and promoting it. But I'm thinking differently these days. I think JavaFX confuses the issue for me.

SAF really is all about making it easier to write Swing application GUIs. The newbie benefits tremendously. Even a veteran benefits because some of the basic boilerplate setup and application structure is already defined. That doesn't change at all. SAF still fills the void there if you're going to write Swing applications. For newbies, it'll get you started in the right direction. For veterans, it might save you some time.

However, most existing applications won't need SAF. Any of the basic problems that the simple SAF resolves have already been fixed in any existing, big application. The effort to retrofit an existing application to SAF is...well, maybe it isn't worth it.

More importantly, don't you really get the feeling that the near and mid-term future of GUIs is JavaFX? Don't you think the vast majority of Sun resources has been going to JavaFX? I really do. So...any newbie in the world of Java GUIs would probably do best to learn JavaFX, not Swing. Considering Sun's efforts to push and promote JavaFX for rich GUI apps, JavaFX is really the right place to put your energy right now -- especially on new development.

Maybe you don't buy into JavaFX just yet because of its short history. In that case, go ahead with Swing and the SAF. But...I think any effort put into SAF is for a short-term benefit at this point.

Enough already. I've said it. The Swing Application Framework was a good thing, but it didn't really get the support it needed in the time frame that would have helped its adoption. Resurrecting it now may be a noble goal, but I personally think the people and projects that need SAF the most are now looking at JavaFX.

Related Topics >>


IMHO nowadays, SAF should be compared to JSR-299 as they may overlap a little. See my post: I have written: "" Today, JSR-299 targets server-side developments, but this is quite an artificial restriction. Most pieces of JSR-299, or even all of the JSR-299 pieces, are useful on the client-side too. A Dependency Injection (DI) framework is quite useful on client-side, just think about Spring Rich Client for one example. And the JSR-299 event model could be leveraged for simplifying Swing event programming. Currently, there are 2 main ways for GUI Java programming: the framework way and the DSL way. For a standard point of view, The Swing Application Framework [is] Still in Coma for the former option, and while for the latter option, some write about Why JavaFX is Intriguing for Java Developers, JavaFX is still too much young. Then, JSR-299 looks like to have a role to play for building a standard Swing framework. And JSR-299 might be included into Java SE, taking benefit from Java SE 7 delay. ""

2cayhorstmann yes i will publish sources for all my JavaFX examples after finishing CRUDfs SDK

@surikov: You claim that your program demonstrates how easy it is in JavaFX to structure a basic app and do internationalization. Can you supply the source to back up those claims?

As I understand it, the sweet spot for JavaFX is pretty UIs, not the "rows and columns of buttons and text fields" apps. But in my world, the need for those apps has not gone away. I don't see why I should have to learn a new scripting language and a new binding mechanism, when there are perfectly reasonable Java/Swing mechanisms that are ready to leave the gate. Sure, I'd like to have some glitz too once in a while, and I hope that the glitzy goodness of JavaFX will be packaged in a form where it is accessible to the Swing programmer without having to fuss with JavaFX Script.

Since JavaFX is not available for Linux and there is not a single even remotely useful real world JavaFX application (not talking gimmicks here) today, JavaFX is simply DOA. Swing is the established cross-platform GUI toolkit. Nearly all our enterprise apps use it. Is it worth it making Swing programming easier? Of course! SwingWorker has shown you can help Swing developers design more reliable programs. If anything can be done to make it easier to design correct, reliable and robust apps for the enterprise desktop, let's do it! Keep in mind that they can be streamed via Java Web Start, thus they are also perceived as web apps. JavaFX has a long way to go to prove its viability. Maybe you should start doing educational software (WBT) with it, where you need to provide some eye candy. But Flash is already there and SVG is just around the corner (the other way around for mobile devices, where SVG dominates). I don't see any enterprise developers doing JavaFX.

I would love to try JavaFX, except it does not work on LINUX, so I'm stuck with Swing. Meanwhile I have to produce now, not on Suns developement schedule.

I think Swing developers should learn from ZK. It does everything you want to do without any fuss. You can write all the code in Java without a single line of CSS or HTML or any tags, or, if you are a masochist, use the tags in zul files just like all the lemmings. Although it's a RIA frameowk for the web, anyone who makes a framework for the desktop which is as easy to work with as ZK will do a great service.

Are you kidding? SAF is absolutely needed. JavaFX is "cute" but it's no replacement for a standard desktop Java app. It can compete in the broswer with Flash and Silver light... do what Applets should have done (over a decade late, after Flash has made the whole effort almost worthless). But you aren't going to write something like Netbeans or Microsoft Word or nearly everything that isn't a toy or a media player in JavaFX - it's the wrong tool for the job. The Swing Application Framework fits perfectly in the void between no framework at all and some heavy framework like the Netbeans Platform. If Sun wasn't so brain dead as to not supply a path to use JavaFX UI components inside a Swing application (yes I've seen the hacks) there would be a case for mixing the two and getting the best of both worlds. For now we have to deal with a rather awkward interface of JavaFX to Java instead of the (much preferable) other way around. Swing is mature... highly extensible, and has a huge base of developers that know how to use it... SAF needs to build on that rather than the JavaFX web-appy frivolity. JavaFX remains a very slow (try the demos on a Mac - when it can't handle breakout you know it isn't ready) and doing your run of the mill object oriented programming isn't all that great in FX compared to mainstream Java. SAF is exactly the thing that is needed to reduce boilerplate code in a typical Swing app. It shouldn't necessarily be in the JRE though.

Sun has provided absolutely no transition path to JavaFX nor a reasonable argument why new projects should use it over other more powerful and mature RIA platforms. It's pretty much a dead-on-arrival technology. That being said, I think SAF is too little. Sun's aspirations with UI building should be to beat Apple's Interface Builder (or even Quartz Composer), not some scripting language. Sun needs to adopt the modularity system in JDK7 more widespreadly, create some UI interfaces, and give desktop users some options. End-users should never know the developer chose Java, and the developer should be able to integrate various platform and library features without piles of heavy/lightweight mixing problems, JNI, or other nonsense.

The JSR page ( lists this JSR as inactive.

@fabriziogiudici There is no sdk for linux or solaris, and the javafx 1.0 mac-version hack-up doesn't work for 1.1. And I don't understand this statement about video support: "While it's an important part of the duties JavaFX is supposed to support, it's also true that not everybody needs videos in their apps." So video is an important part of javafx, but it's not really an important part? I don't quite understand. Sun apparently thinks video and audio are very important, as they are using it as the reason for not releasing an sdk for linux or solaris. At least that's the claim made in the (now rather dubious) post "A Word on Linux and Solaris Support" at "" It's very upsetting to read a blog article saying that an improvement to swing is a wasted effort because of javafx when the editor at tells linux and solaris platform users to suck wind ("") and fantasize about free codecs because Sun has better things to do than support javafx on those platforms. For linux and solaris developers, Swing is all there is.

@joconner "I personally think the people and projects that need SAF the most are now looking at JavaFX". But maybe its the other way around and JavaFX is the enormous waste of effort. Designers will go on using Flex not because it is a better or worse language but because they use the Adobe tools. And that won't change because of a scripting language that has declarative elements. The "ecological niche" of Java would be seamlessly working web-start applications. Therefore we need a modernized Swing (and Java3D). Flash and any imitators are not appropriate for serious rich clients and I personally (and anyone I talked about it) are not too much interested in using a special language for the GUI especially as I think declarative interfaces are not a very good idea for GUI applications. (I would have rather use serialized objects as in Cocoa). Additionally I think Java has had its success because of the many mighty allies. Have you heard any positive word about JavaFX from IBM, Oracle and the like? No, nothing. I would think they prefer AJAX or Flex for this kind of interactive web-interfaces. (My personal favorite is AJAX and GWT in this arena). And Sun should stick to Swing, one of the most successful GUi toolkits. I think it is very unlikely that JavaFX will come anywhere near to Swing in terms of popularity. I think it is a pity that Sun uses so much of its dwindling resources for the JavaFX experiment with uncertain result. So if Sun neglects Swing I will use SWT. With JavaFX I think it is much wiser to wait and see. Most things in computer industry are just hype that no one needs and uses in reality.

I agree with Wade here. Some nice, easy to apply animations would help spruce up our Enterprise apps some, but there is nothing JavaFX has to offer otherwise. Declarative UI? We've had that with JFormDesigner for the past 4 years now with a tool to easily build them, so that isn't a benefit. Easy binding you say? We've had JGoodies Binding for the past 4 years also. It's one line of code. I'm not quite sure its worth the effort to try and improve on that. Does JavaFX have some declarative way to handle validation with nice looking feedback? Swing developers have JGoodies Validation for the past 4 years that's very easy to use. Last time I checked, JavaFX didn't have a lot of the components that Swing has, so I think it's a bit premature to start the funeral procession for Swing at this time. Oh yeah... you can easily add them by creating some custom wrapper. How does that make development easier for me again? I do agree with John that SAF might not be worth the trouble since many of us have already solved the problems that it tackles, but i disagree that the focus should be on JavaFX. In my opinion, Sun will need Swing developers to be on board for JavaFX to gain widespread acceptance, but so far, they seem to be alienating them instead. I don't think it is intentional, but that seems to be what is happening. Personally, I think Sun should ensure the interoperability between Java, Swing, and JavaFX in all directions. Swing developers could leverage JavaFX, JavaFX could leverage Swing, etc. Better for Swing developers, better for tag-monkeys, better for Java.

SAF should not be integrated with jdk.

@sunburned: the current JavaFX runtime can be used with Linux and Solaris, AFAIK the only missing point are video codecs. While it's an important part of the duties JavaFX is supposed to support, it's also true that not everybody needs videos in their apps.

Look at this application This is JavaFX text editor based on CRUDfx SDK CRUDfx SDK implements all requirements from jsr296 ( Localization - the GUI has 3 languages and can be translated to other ones by editing of a XML file The user properties - the size and position of windows, a folder for the files, the chosen language, the chosen skin and so on are kept in a home directory of the current user Themed GUI - the user can choose any Substance theme

I will probably start a war here again, but... Why should we be forced to do an application in a new, scripting, not very structured language? (JavaFX) I admit the new features is what we need, such as binding, but why in a completely new language??? I really don't understand

Considering that JavaFX is not available for linux or solaris users, what else is there but swing-based solutions for the systems that Sun has orphaned by abandoning the write-once-run-anywhere principle?

@jareed agreed. But once again, in the enterprise world, people don't know (or don't want to know) Groovy. They only want either Java or C#. It will take a looooong time before this can change. In the meantime, SAF is an important part of the desktop jigsaw puzzle in Java Desktop.

I'm more excited by Griffon ( than I am by either the resurrection of SAF or the development of JavaFX.

@wadechandler I second that! It seems the author has a narrow view of the IT world for enterprises. Today most custom systems (in Java) are either Web (J2EE) or Desktop (Swing). Enterprises are not ready for a change to a new language (how long did it take .NET to get accepted in some enterprises?). In addition, I would say that Sun people also look disconnected from reality when it's up to JavaFX; it's just like they want to feed tigers with a candy;-) @viero for JavaFX I don't know any ;-) For SAF, there is HiveBoard (my OSS project) and NASA has also an application (can't remember the name). In my company we have also developed our first SAF application (custom development for one of our customers) last year.

... show me an application built on top of [ SAF|JavaFX ], and I'll consider using it for my next project.

In the same vein of Swing being around for many years to come, is one more likely to rewrite an application to use JavaFX if they already have it in Swing or to continue using Swing based technologies? For instance, what about a business application or a client server front end? What gain will be achieved by rewriting everything to be in FX? None that I can see. Now, having the two compliment each other makes a lot of sense. For instance, Swing is good as a set of components and beans which can be used to throw together a nice UI which works with our normal input methods for business cases and many others with out input methods of today. For instance, how does a fancy animated and graphical UI help get data entered into a system or write a Word document? Now, often a view to pick colors, fancier view, or a video or animation view is needed, and this is where JavaFX shines to me in the grander scheme of application development. JavaFX would be a great base for a video game API or DVD front ends or some other animation based kiosk etc. In those cases it beats Swing. I don't really see a time, until all the tooling and components out there for Swing are brought over and it is as easy to tie into the full programming and drawing architecture as Swing allows, that JavaFX will be able to replace Swing, nor do I see the need for Yet Another Swing API for animation and media when we have JavaFX. If Sun would put the small amount of energy into JavaFX to make it work standard as a Swing->JavaFX and JavaFX->Swing technology versus only JavaFX->Swing as a standard API that would benefit Swing and JavaFX developers more than spending all their time, as it has to be limited these days, trying to make JavaFX do everything Swing can do or vice versa. Too, there is the NetBeans Platform/RCP which is great for building Swing Applications. The Swing Application Framework can't really compete with the NB RCP technology for a Swing Framework. In my opinion the NB RCP is where folks need to be, and Sun would do some good things were they to put more effort back into Beans Binding and SwingX in the context of the NB RCP along with other things such as a client/server model for EJB and other EE technologies, login and remote user support, and other business class application needs in the base platform. Take those things and tie in JavaFX and they could have a very compelling client/server Swing and FX based RCP for many types of application development. Then folks could use those things together or apart depending on which needs they had to address.

NECESSARY CORRECTION: "... is not capable to deliver a desktop application..." is plain wrong. Sure it is capable to. That sentence should be re-phrased "it makes not an easy job to deliver..."

Debating the topic at large would need to include in the comparison a lot of other stuff - I prefer to keep focus on Swing/SAF and JavaFX. In the perspective of this comparison, it makes a lot of sense to keep on with SAF. While JavaFX's future will bring us a lot of thing, it's quite clear that for at least the whole current year JavaFX is not capable to deliver a desktop application from moderate complexity up. While it makes some basic things much easier (such as data binding etc), there's no such thing as a framework at all. I mean, with just a couple of clicks you have a complete desktop skeleton (and following some popular "patterns" such as menu, progress bar position, etc....) up and running; with JavaFX you need more work. On the other hand JavaFX is undoubtly more productive for bringing up applications with more exotic look and graphical design. In the short / medium time Swing and JavaFX are clearly complementary. For the longer run, things might change - even though I think that Swing will have a role for many years from now.

Totally agree. At this point in time, I think SAF is starting to look more and more like it's trying to solve yesterday's problems. It's benefits are at best short term, and any productivity gains delivered through SAF will pale in comparison to what JavaFX will provide, particularly as I gains a richer set of controls. I'd really like to see those resources diverted instead to beefing up the various aspects of JavaFX runtime, like performance, fast start up, multithreading support, more controls, 3D, etc.