Ben introduces an interesting concept ... container managed Swing. I've also seen this idea pitched from a IoC container perspective for managing dependencies.
I don't think a container to leverage for threading issues would be horribly hard to do. Basically you'd be forcing developers into a pattern of development that would make their code play nice with threads. In many ways this is what SwingWorker does except without handling things on the component enablement/disablement side.
Microsoft Technical Summit, Threads, and Swing ...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).[3] 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.)...
Previous Topic
