Frank Sommers iniciou uma discussão interessante no Artima, o quanto de concorrência as biblioteas visuais que nós utilizamos disponibilizam e o quanto isso é necessário?
Quem já trabalhou com Swing sabe que você só pode alterar o estado de um componente de dentro da thread do próprio Swing (usando as classes SwingUtilities ou EventQueue) pra registrar os “runnables” que vão executar o trabalho. Fazer uma alteração em um componente Swing de fora dessas threads vai ser trabalho perdido. O SWT, a biblioteca de componentes do Eclipse, é ainda mais dura, a invocação de qualquer método em um componente visual de fora da thread de desenho faz com que o método lançe uma exeção e o programa pare automaticamente se ninguém tratá-la.
A decisão de ter uma thread única para execução de eventos foi uma necessidade na construção dessas duas bibliotecas, mas hoje com as aplicações AJAX e os clientes ricos executando em um modo “thread única” alguns conceitos estão mundando, mas um modelo de thread única pode fazer a aplicação congelar enquanto espera a resposta da ação.
Mas então, você acha os modos de trabalho do Swing/SWT trabalhosos demais? APIs mais simples como o Flex resolvem o problema melhor? E os trabalhos longos, o que fazer com eles?
Discussão: How Much Concurrency Should be Exposed in a UI Toolkit?
