From my experience (one year Qt, several years of Swing).

Swing:

• Pro:
  • Available on any Java installation. No need to ship any additional code
  • You can write your own custom widgets in Java
• Contra:
  • Swing is old. There haven't been any updates on the core for years and there won't ever be. If you plan to use Swing, get a good wrapper which will make using Swing much more simple.
  • Swing is hard to understand and use, especially if you're used to UI programming on Windows. (One word: Layouts).
  • Not many powerful widgets in the core set. You'll especially miss a good data grid.
  • For a good look&feel, you need an extra library

Qt:

• Pro:
  • Comprehensive set of powerful widgets
  • Easy to use and learn
  • Good documentation
  • Good support
  • Active development
  • Uses native widgets and wraps them in a common API across all platforms
• Contra:
  • You need to ship extra files
  • Qt is written in C++ so you're accessing it via a wrapper library. If you need to implement a complex custom component, things can get hairy.

If you can hire a seasoned Swing developer, give it a try. If you can't and if you have to start from scratch, I suggest against Swing. With Qt, you'll have results within hours and with only little hair pulling. Swing is powerful but it makes no attempt to hide this fact. So you'll find yourself struggling a lot with the API and the defaults which have made sense in 1996 but not anymore today.

Qt has a much steeper learning curve and the API is much more consistent, not to mention that Qt has been improved the last seven years while Swing hasn't (see below). KDE is based on Qt, so there are lot of people out there using it and most of them have only little time (say a few hours here and there) and most can handle Qt after a short time. Which you simply can't say for Swing.

There is a lot of Swing documentation but most only covers the common cases which you can figure out yourself from the Javadoc. If you need something more complex and if you're looking for a bird's eye view, something which gives you a feeling how to combine things to achieve the desired result, I haven't seen anything free and I also can't recommend a book for Swing book because I have stopped looking at them five years ago.

If you look at Java 7, then you'll find that Sun is thinking about working on the Swing API. But: Java 7 is due in two years, there is no commitment for this work items and last but not least: Can you switch to Java 7 when it will be available?

Update: It seems that there won't be any Swing updates for Java 7 ^[1] after all. Which is a pity. It will leave us with a built-in UI framework from the late 90's which just isn't on top of the times anymore. Being an old Amiga lover, I know how it feels to be abandoned. Thanks, Swing, it's been a nice time.

I completely disagree with Aaron Digulla's entire answer as it pertains to Swing.

I have found Swing to be, while not the best design and a little convoluted, reasonably simple and workable, and ultimately quite well thought out. Further, it most definitely is capable of what is required for almost all GUI app's.

Using the native LAF, the application will look and function enough like a native application to receive a passing grade (IMO).

As to the bit about layouts... it's true that the Swing layout's are a little hard to use and need nesting (sometimes a fair amount thereof) to get the desired results, but the concept of Layouts are one of the best things about doing GUI's in Java. Take the time to understand what they do for you and get yourself a good table-based layout (e.g. MatrixLayout ^[1], TableLayout, JGoodies FormLayout or MigLayout) which will eliminate 99% of the nesting. A table-based layout will also make your GUI simpler and will make the code better reflect the end visual result.

So, my advice is that if QT does things in a way in which you would prefer or provides functionality that Swing doesn't, then by all means look into it - provided that you are happy with distributing it's Java and native components with your app, and that it targets the platforms on which you want to run (or may want to run in the future).

Otherwise, it's hard to beat Swing's flexibility, the fact that it's baked into every Java install and it's ability for you to easily tailor look and behavior.

Oh, and to be fair, I have not looked at QT before - But I have about 6 10 years of active Swing and AWT development, comprising 1 commercially deployed AWT application and 3 such (non-trivial) Swing applications, plus a number of personal Swing apps. Perhaps more important is that I have implemented a fully-functional lightweight GUI toolkit on top of AWT, very much analogous to Swing but with a completely different component and event architecture which has been successfully deployed commercially.

Be aware that Qt Jambi will be discontinued shortly. http://www.qtsoftware.com/about/news/preview-of-final-qt-jambi-release-available. My interpretation of this is that following the March 4.5 release, Jambi will be in the same boat as Qt bindings for other languages - up to the community to maintain.

Regarding your questions, I have a few years of Swing experience and I've been working with Qt Jambi for the past month, and I'm pretty mixed.

On one hand, I'm particularly disappointed with Qt's model/view paradigm. Creating an editable tree in Swing, by contrast, using a completely non-Swing model, is a breeze. A couple of hours work. After a week of struggling, I've come to the conclusion that it's just not possible to do such a thing in Jambi 4.4. (Dunno about 4.5) The only solution I can find in Qt is to tie data to the Qt model classes by subclassing QStandardItemModel and QStandardItem. (While QAbstractItemModel is very capable in C++ Qt, it's literally unusable in Qt Jambi.)

On the other hand Qt Jambi gives me access to the amazing QGraphicsView drawing tools, and I don't know of a Java library that can compare. To me, that's the power of Qt Jambi - it gives you access in Java to excellent 2D and GL drawing tools that really aren't available in Java otherwise.

My advice is that if you need to build an application that uses only standard UI widgets like tables, trees, menus, etc., then just use Swing. Layout in Swing is not that hard, really, especially with tools like NetBeans. However, if you need GL or a canvas to paint on, Qt Jambi might be worth looking into.

Pete's comment ^[1] is right on. For those who need a more powerful swing based toolkit, check out Jide http://www.jidesoft.com/.

As far as Qt vs Java ^[1] PDF Deepak has presented, it clearly was written many years ago. Since then Java's virtual machine has improved tremendously, so memory and performance issues are not an issue anymore. The article discusses even the validity of using garbage collector, which I find hilarious!

Next, discussing programming models, signal-slot model has been presented as superiour to MVC, with only measurement being number of the lines of the code required to achieve same effect! What was overlooked in that document is that Java's code is clearly self-documenting, unlike Qt's.

I'm not saying that Qt is worse than Swing. I'm just saying that that document should NOT be used as an argument. First two answers give the best description of both frameworks discussing it's strenghts and weakness alone, without comparing programming models and pulling conlusions out of a thin air.

As far as Qt vs Java ^[1] PDF Deepak has presented, it clearly was written many years ago. Since then Java's virtual machine has improved tremendously, so memory and performance issues are not an issue anymore. The article discusses even the validity of using garbage collector, which I find hilarious!

It’s also old when it comes to Qt:

The Qt toolkit follows a similar approach; like Swing, it only relies on the native libraries only for very basic things and handles the drawing of GUI components itself.

This is not true anymore, Qt now uses native widgets. It no longer emulates them.

I don't know much about swing, but I'd like to react to Adeel's answer regarding Qt.

I don't think finding experienced developer in Qt should be a showstopper : it is very easy and fast to learn Qt. The documentation is very good (that's maybe the best part of Qt : its documentation). IMHO, the Qt community is great and I always found the help needed when I had problems. There is many forums (QtCenter.org, QtForum.org and others) and Trolltech is running a very active mailing list.

To correct Adeel's comments; You can ship your software commercially - you just have to include the source. There are thousands of developers with Qt experience (KDE). Qt is standard (used by KDE, Nasa, ESA, Adobe, Skype, etc), There's a large Qt community and many books, and the Qt Jambi product is quite new so it's not surprising it's not that well known yet.

I think the most important factor you should consider is that Jambi QT is going to be discontinued ^[1] from active development.
Swing isn't that of a recent product as well.
You should also definitely consider SWT since in my opinion it generally looks better than Swing.

Qt is far better than AWT/Swing. I have been using Qt for past three years and have found absolutely no issues in application development. Compared to Qt(C++), Swing(Java) loses out in run time efficiency and memory efficiency. You may get a lot of Java/Swing resources easily, they are hundred a penny but if you can hire a good Qt/C++ application developer, thats the best choice I say. No offence to Java developers but you have to accept the facts. Qt is available with LGPL licensing.

I did not see anybody mention about its cross platform support and the way it is implemented. There is tremendous advantage for Qt there.

Great documentation, Qt's own intuitive IDE(QtCreator), lotsa examples, and a great and fast growing community out there for support!

Regarding shipping extra files - there are packaging solutions available.

Read more here link text ^[1]