For the sake of argument, I'm willing to accept the assertion that Swing has improved significantly, but I wonder why there don't seem to be any Java applications which use a Java GUI toolkit which don't feel slow. Rendering is noticeably slower, control interaction is perceptibly slower, and even simple text entry can seem slow.

I've been interested in Spaces because I think the field is overdue for some innovation but each time I try it, I give up because its GUI is unusably slow. Fair enough, Spaces is still in beta but . . . every Java app I have used exhibits this to one degree or another. Very simple apps and ones where the developer has spend a great deal of time tuning the display code are usable but they're never snappy, even by OS X standards.

(Based on experiences using a the 1.4 OS X JVM on an 800Mhz iMac, or Sun's latest for W2k on a 1.2Ghz Athlon and 1.8Ghz P4, all with a boatload of memory and decent video cards)

The one exception to this is the native code: Apple's Cocoa-Java bridge is indistinguishable from native code except that small Java apps take slightly longer to load than small native apps (the difference is in the noise with larger apps). Having come from a server-side Java background, Cocoa-Java was the first thing that made me consider Java applications plausible for GUI applications, with the major caveat about portability (fortunately, portable logic + platform-specific GUI isn't a major loss and you do end up with an app which truly indistinguishable from a native program, unlike Swing's emulation).

The point of this rant is simply that I think the article demonstrates the sort of tunnel-vision which has held Java back. Sure, Swing may be faster than it's ever been but it's nowhere near native speed - forget SWT, Swing needs to be compared to native widgets using more realistic tests. The 10,000 row table is too artificial - most people work with hundreds of records, not thousands, and most programmers working with large datasets have learned to do paging so they only process data which is actually visible. I'd be more interested in real-world things like menu responsiveness, window resizing or scrolling speed in a paged list-box / table implementation - areas where a few extra milliseconds can give your application a lasting reputation for sluggishness.

My server-side work & experience with Cocoa-Java makes me want to defend Java but I simply cannot when it comes to anything GUI-related. Java's going to keep its second-class reputation until it's indistinguishable from native code and the widgets behave like native widgets in every aspect. I'm worried that Sun's developers are reacting defensively to SWT and losing sight of the real goal. With .Net around, I don't think they want to keep a system which requires a good deal of developer time to reach the "slow but usable" stage.

what do you think about the idea of using flash for the GUI, with a Java application running the logic?
Sesma has a piece of software they're calling jFlash that allows just that.

what do you think about the idea of using flash for the GUI, with a Java application running the logic?
Sesma has a piece of software they're calling jFlash that allows just that.