Alex Prayle,
can you provide a code sample to demonstrate an "efficiently implemented TableModel" ?

... that SWT in combination with one third-party tool enable GUI Java apps to be distributed as compact native Windows EXEs running without the JRE?

http://www.excelsior-usa.com/jetswt.html

This could have been possible with AWT/Swing apps too, if Sun JRE license was not too restricive...

The dot com boom had to be the worst thing for client side development in general. Coding a proper client takes as much skill as any server side process. The problem is that most developers have not cultivated the proper skills for client side dev, focusing primarily on the server side and HTML clients. Further more few frameworks provide more than just a handful of widgets; Swing and SWT are both guilty of this. As far as Swing performance goes, its not a problem. I have implemented a next generation client side UI framework using IntelliJ as my dev environment and the framework is built on top of Swing. I use to code in Netbeans which is a complete dog. IntelliJ is blazing and guess what? They turn off directdraw for the Java2D subsystem by default! Note: The GDI in Windows XP is blazingly fast compared to previous implementations.

Bottom line. If a Java client side application is slow blame the developer or the hardware, but leave the widgets out of it because it ain't them. As far a JTables go when designing your table models think JDBC and scrollable result sets.

Hi,

The first thing I have to mention SWT is not a true cross platform library. Trust me I program in both the Swing and SWT.
a) Each platform support requries to write huge amount of code. Just check the SWT source by yourself. While windows x86 implementation is more or less production quality, the other ports are vary from alpha stage (MacOS, PocketPC) to early beta(linux).
b) With every added platform SWT development becomes slower and slower because API was designed by Windows programming people who knows nothing about other platforms.
c) SWT was designed not as an Standard widget toolkit, but as Eclipse widget toolkit. So, if you are designing application that doesn't look (behaves) like eclipse then you are in trouble. Just check eclipse.tools forum or TRUST ME.

The problem of Swing is not the speed but low qualified developers. Just try to compare borland JDeveloper (dog slow) and IDEA that runs at reasonable speed.

Some interesting open source alternative to AWT and Swing. Support nearly all java versions (starting from 1.1)

Check online demo (should work in most browsers including IE):
http://www.zaval.org/products/lwvcl/demo/index.html

For those who believe that Swing is a great UI system, feel free to use it.

Personally, I am almost GRATEFUL that SWT has come along to provide me with a UI for my Windows-based Java apps. I have now built major apps with both Swing and SWT, and the SWT user experience wins, hands down. Swing tends to be slow and frustrating. SWT is almost universally snappy and responsive.

Not only that, but SWT allows me access to the wide world of ActiveX objects. In particular, I have been able to script MS Excel from within my Java app - a very useful feature for those who write business apps, since a lot of worthwhile corporate data is ferreted away in Excel workbooks.

SWT is the right choice, abstract enough and native as it can be, it must be promoted to standard.
In fact SWT can be described as AWT made without excessive haste.
When the Java developers had to create Swing, they must have thought that trying to use native toookits under a thin layrer of abstraction was too difficult.
Designing a new toookit from scratch with its rules and look and feel was more attractive and rewarding for the developers.
The look and feel of the platform could be easily emulated, they thought.
The outcome is that you have a java look wherever you go. Even with emulation you have two pitfalls. One: it is not perfect and you can tell it is not native (jgoodies can do something about that); two: seeing a Java application trying to have a Windows 2000 look and feel when you are running XP is funny (nice try, swing).
This is the original sin: putting all Java developers in a ghetto for the imposssible quest of the universal look and feel.
Further, the tipical Java application has a "Franken UI" because most defaults are not well chooosen.
Look carefully at www.jgoogies.org and it will be clear how far a little tweaking can take Swing.
Mozilla went the same way, but at least XUL makes things much easier, because any web developer that knows XML and JavaScript can change something in the interface.
If I had to use Swing (happily I don't), I would fix it with the jgoodies library, but if I had to develop something with a user interface I will take the SWT path.
All in all, Java on the desktop is just as appealing as Python with Tkinter: nice language horrible look.
Luckily there are servlets, where Java really shines and one can do the presentation in a number of ways.

Conga is Java's fastest and easiest way to create rich GUIs which are 100% Java.

Have looked at SWT and Swing, and am convinced that you can get a lot better mileage out with Conga.

Rather than unsubstantiated opinions, has anyone actually actually done some benchmarks? I'd love to hear about even one operation well implemented on SVG and Swing in which one was better than the other.

Also, if SVG really is better than Swing, is that because C++ in the O/S is faster than Java? That would be a serious criticism. Maybe adding things like C# Struts to Java would help...

First, Eclipse doesn't promote anything- it's an open source community. Secondly, the reason there isn't a GUI Builder was for political reasons more than any other. IBM had to spare Sun the final embarrassment of releasing something that was conceptually superior to anything Sun ever released.

Considering that Swing performs nicely under Mac OS X(*), the problem seems to be that it is not Swing itself but its implementation on Win32 and Linux. Sun cares far less about Swing than Apple does it seems... pity. If it did then Swing and Java on the desktop (on the 3 major platforms - Mac, Windoze, Linux) would now probably be a lot more popular than it is right now.

I don't mind the non-native L&F as the whole point of Swing is to be _cross-platform_ standard.

(*) I don't know if its a memory hog under Mac OS though...

All you have to do is look at products like IntelliJ to see that Swing can handle it, and it will only get better.

The argument that Swing doesn't look like Windows or its native OS and therefore its a bad option is completely ludicrous.

Applications these days come in all sorts of look and feel. Just look at all those multimedia players. They don't look anything like Windows. Windows XP doesn't look like Windows, people are used to seeing different kinds of windows, and guess what, people don't mind!

A fair comparison of Swing vs SWT is to look at IDEA. IDEA is at par with Eclipse's capabilities, but its written in Swing.

What the Java world needs to do, is to follow the lead of www.jgoodies.com , what that means is to make it easier to write Swing applications that look good. Swing is highly capable, the big question though is that if you're a novice, can you write something that looks nice?

I think this article is born out of pure ignorance, the fact that it comes from this magazine is embarrasing. Furthermore, the Eclipse project doesn't promote the use of SWT outside of the IDEA, if it did, you would have a gui builder for SWT. If you did benchmarks on the table class for SWT, you'll find it doesn't perform as well as Swing.

Operating systems have a look and feel that users get used to and feel comfortable with. Deviating from that L&F is asking for trouble. I'm sick of jumping through hoops to make Swing apps look, feel, and behave like native OS applications. SWT is the right philosophy - When in Rome do as the Romans...or your app will end up in the catacombs.

At some point swing might end up somewhere close to native UI in speed and performance.But it still is a memory hogging beast. Just take a look at the amount of memory consumed by the leading java IDE Intellij and Eclipse. Moreover why should the user sacrifice the look and feel which he is used to in his favourite OS.
Most of the applications can do without custom Widgets. At least , that is what we should assume from the millions of web applications we see around.
I strongly believe SWT applications on Java web start can fill the gap for a true clientside low footprint applications platform. That will ultimately help java reign the desktop the way it did with the server.

It amazes me that this debate is still alive. If it weren't for the relative immaturity of SWT, we wouldn't even be having this exchange. SWT is technically superior to Swing in every way that's important. If you've invested alot of time using Swing, that doesn't mean you should stay invested. The stock market thud seems like a good analogy.

I fail to see the large-scale advantage of SWT. Extending even a simple widget (which is inevitable, except for uninteresting GUIs) is a PITA. If your sole target is windows, then why not just code in C#? And if it's not, do you really want to invest the extra cross-platform coding and testing time for SWT? Because in order to use native GUI components, you have to use the data models for those native components.

I do most development on OSX, so maybe I've just never seen this "huge" speed advantage (yes, I've tried eclipse on both w32 and OSX). And a speed advantage alone has never succeeded in supplanting solutions which in the end are easier to manage or develop (VB, anyone?)

Just look at any Java IDE based on Swing, e.g. JDeveloper from Oracle. Great stuff, but SLOOOOOOWWWWWW. Then check out Eclipse. Even better than JDeveloper and very comparable. Great stuff and lightning fast. To realize that all these years we have been punished with Swing and AWT while we could have had SWT (or something similar) is mind boggling. Let's hope SWT becomes part of the standard.

In my project I am using JTable with 10,000 rows and 35 columns and the performance is quite satisfactory even on W2K PII 400Mhz 256MbRAM & JRockit 8.0.

A JTable with an efficiently implemented TableModel can handle far more than 1500 entries with ease.

I've just experimented with and editable JTable with 100000000 rows x 1000 columns, it runs without any problem and in my opinion it is very responsive.

(600 MHz PIII 256MB RAM)

I would think Sun probably needs to make an arrangement with IBM to use SWT, even if IBM supports it, instead of writing their own, but what do I know?

Swing COULD do it, if SUN implemented a natively acclerated interface, or allowed someone else to do so they way they did with Apple's implementation of Swing accleration on OS X. If you haven't seen it, Swing is very much faster under OS X, mainly because it has a good underlying implementation. Because of the lack of such on Windows I have been heavily researching using SWT in my next desktop project.

JGoodies are very cool I use Disk Report all the but what JGoodies do and what eclipse do are LIGHT years apart. One is a neat utility (JDiskReport) and the other is an enterprise development environment.

Swing is great for simple small stuff but gets tricky with larger things. Try having a JTable with 1500 entries and see how well Swign does with that. Do it with SWT and it is wicked fast.

It will be a short message : www.jgoodies.com