SwingWorker, Secondary EventPump, JIT Cache Bwtween Runs, ...
Sun has posted the transscript of a SDN Chat Session about Desktop Client. The parts I liked the most are:
JavaGeek: Why hasn't the SwingWorker (or a similar mechanism) made it to the standard APIs? What is the recommended way to deal with process-intensive tasks?
Scott Violet: Excellent question. It turns out we're very close to finishing up a version of SwingWorker that will be part of 1.6. This is the version that Igor, Brent, Bino and myself talked about at last year's Java One conference. This version of SwingWorker is generified and supports property change listeners. It's extremely handy. I'll also mention that AWT is looking at a way that you can pump events during a long running process. Other toolkits provide similar mechanisms and it turns out it's very handy.
markyland: Are there any plans to allow Swing applications to be compiled natively?
Scott Violet: The closest thing I can say we're looking into is persisting compiled code between runs of the JVM. For example, each time you run your application we end up compiling a lot of the same methods; if this were cached it could conceivably speed things up. Whether or not something like this makes it in depends upon the results we get.
JNB: JGoodies Forms
Lance Finney writes about JGoodies Forms in the March issue of OCI's Java News Brief (JNB).
I have used JGoodies Forms in the past and liked it a lot. Like all LayoutManagers in Swing, JGoodies Forms takes a little while to learn and understand. Unlike some of the other LayoutManagers, once the understanding is in place, once you get it, the actual using of it is more natural.
If you are in the "I'd rather create my GUI in code" camp, as opposed to the "I'd rather paint my GUI graphically" camp, JGoodies should be able to help you in many situations.
You are still writing Swing applications, aren't you?