Microsoft Technical Summit, Threads, and Swing
Like a few other vocal bloggers, I attended the recent Microsoft Technical Summit (a.k.a. Developer Influential Seminar, a.k.a. Java/.NET Interop Event). I was warned beforehand that MS serves a lot of kool-aid at these events, and that's no joke -- I think they spiked the punchbowl.
I've waited to blog my own impressions until I've had a chance to digest what I've seen and let the "Wow" factor dissipate. I'll write up a few thoughts on the event here and there in coming weeks, starting with this entry.
"I don't think shared state will be a viable solution for concurrency; it doesn't scale -- there aren't enough Ph.D.s in the world."
He went on to say that he thought that the Servlet/ASP model of concurrency might be the future of a C# concurrency model; Servlet/JSP/ASP developers are largely insulated from the complexities of threading while the container does the heavy lifting.
This rings true with me. You see, I've gotten to know Swing very well over the past few years. While some advise Swing developers to avoid spawning threads as much as possible, developers wishing to create snappy, high-performance Swing GUIs will need to do the opposite: aggressively utilize an asynchronous multi-threaded architecture.
And there-in lies the rub. As if the Swing API weren't complex enough, it turns out that wrangling with highly asynchronous multi-threaded code bumps up against some of the toughest problems in modern software development. Just ask the thread wizards of Javaland. And you were hoping VB ex-pats could start doing Swing development? Hah.
So of course, to get any large-scale Swing application off the ground, and have it perform well, you'll need some sort of framework that makes handling multiple threads easy. And there-in lies, err, another rub.
It turns out that there is no such framework for Swing. Now, there are utilities here and there. SwingWorker, FoxTrot, Spin, Somnifugi (such as it is), and the upcoming and still-secret fancy-pants new uber-SwingWorker all promise to make the act of spawning the thread and then getting the updates back on the AWT thread easier.
But really, that's not the root of the problem. The problem is that developers have to worry about something that low-level in the first place.
For the past year or so, I've been noodling ways to make concurrency in Swing easier. I don't think making it easier to spawn a thread is the answer. I think removing the burden of worrying about threads is the answer. And how do we do that?
Container-managed Swing. That is, a framework where screens and event handlers are managed by a "container" that automatically handles threads. Asynchronous screen population in the background, expensive user operations spawned by event listeners -- all managed by a container that does the heavy-lifting (including disabling the interface and displaying progress, where appropriate). Just as a Servlet developer doesn't concern herself with managing a pool of worker threads to handle incoming HTTP requests, a Swing developer shouldn't need to worry about managing threads. (Just as a Servlet container does a lot of other things, so should a Swing container -- but that's another blog entry.)
When I first implemented these ideas to support a Swing project, the notion of "container-managed Swing" was far from my mind. But after hearing Anders' remarks, I realized that its exactly what I had created.
At No Fluff Just Stuff conferences throughout the year, and at JavaOne, I'll be sharing this idea (and a host of others) in more detail. When I first picked up Swing a few years ago, I was shocked to learn that virtually no literature existed discussing how to architect professional-grade Swing applications in any detail. Over the past few months, I've seen hints of such content gradually emerge. I hope my presentations and blog entries like this one can add meaningfully to the discussion.
Or, we could just implement
DoEvents in Swing and let VB'ers work the way they've been working for years. (Hey, it'd be pretty easy... maybe it's not such a bad idea?) ;-)
 I have immense respect for the writers of the linked article. Managing threads is way too tricky for most Java developers. But, unfortunately, creating professional Swing applications demands it.
I just had this point re-emphasized yesterday. I was sitting on a light-rail train when I bumped into an old friend. He was talking about an app he was using (which I knew to be Swing-based). He said, "It's way too slow!" They upgraded all their computers (more memory, faster processor, faster video card) to fix the problem, and guess what? It didn't get any faster. Standard symptoms for under-aggresive use of threads with Swing.
 NetBeans includes a dumbed-down version of SwingWorker in its API, and Spring RCP leaves threading as an exercise for the developer. (Though given the lack of documentation for both projects, I could be wrong and I'd love to know if I am.) Besides, both platforms aren't ready for prime-time. NetBeans has very little documentation indicating how to use it as a platform, and Spring RCP development has been stalled for some time and has yet to make a formal release of any kind.
 JFace certainly makes life a lot easier than any of the Swing frameworks I've seen, and Eclipse RCP adds more to the picture. But, that's only if you're using SWT, and besides, those frameworks don't quite go far enough. But, more on that in another blog.
 I really don't know if I like the "container-managed" label or not. It's just that "framework" is so ambiguous as to be meaningless. So for now, I think I'll keep using it.