Programação concorrente e bibliotecas de componentes visuais

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?

Tanto o Swing quanto o SWT tem esse modelo porque foram projetados para serem extendidos.

É extremamente complicado, sujeito a erros e frustrante tentar extender um modelo visual thread-safe, ou que tem muitas preocupações com concorrência. Se você não souber exatamente o que está fazendo, certamente recairá em deadlocks ou a códigos com comportamento inesperado e muito difícil de depurar.

O fato é que, o modelo single-threaded é muito fácil de ser compreendido e extendido, mesmo por programadores pouco experientes. Abrir mão desse modelo seria também abrir mão de parte do poder de extensão que o Swing tem.

Não estou negando que falta para o Swing mais suporte para isso. Realmente alguns frameworks terceiros facilitam muito a tarefa de manter esse modelo, ou mesmo automatizam atividades recorrentes (tal como o desenho de barras de progresso, por exemplo). O a própria versão release candidate do Netbeans exemplifica isso com maestria, quando nos apresenta um modelo task-oriented extremamente simples de se usar.

A grande dúvida é... precisamos realmente extender o framework gráfico? Ou é papel desse framework nos fornecer classes boas o suficiente para que não nos preocupemos com isso (filosofia por sinal da VCL e do VB)?

Eu, particularmente, acho que a decisão sobre como o Swing é estruturado foi acertada. Só falta agora, polir um pouco o framework, aparar algumas arestar e tornar a programação dele mais agradável.

Um artigo falando sobre o assunto...

http://weblogs.java.net/blog/kgh/archive/2004/10/multithreaded_t.html

Notícias, artigos e o maior fórum brasileiro sobre Java