Lendo Swing vs. SWT, do Amin Ahmad fiquei bastante indignado com o ponto de vista dele. Na prática, o artigo dele é um contra-ponto (bastante forte) sobre o artigo SWT Happens. Amin parece defender o SWT com unhas e dentes. Mr Ed, parece ser mais pragmático.
Pelo que minha pequena mente percebe, o sr. Amin faz uma comparação entre o Swing e o framework do Eclipse. Daí é Davi contra Golias e isso não serve.
Comparar uma API contra um framework não tem sentido algum. O Swing é uma ótima API MVC, com recursos escaláveis, flexíveis, robusta, estável e com bom (ainda não ótimo) suporte para look and feel. Tem mais coisas, mas isso basta. O SWT é uma contrapartida da IBM que objetiva maior facilidade de desenvolvimento (e por isso seu modelo MVC não é completo), performance mais elevada e comportamento nativo. Na prática, até que me provem o contrário, o SWT é o seguinte: se o controle existe no Sistema Operacional, então o SWT usa ele (tal como o AWT faz o conceito de peered controls); se o controle não existe no SO, então o SWT renderiza ele totalmente (via API 2D) na forma mais parecida com o controle nativo. É do comportamento peered do SWT que surge a necessidade de uma DLL no Windows ou uma SO no Linux para seu funcionamento.
O Swing renderiza tudo sempre. E por isso dizem que ele é mais lento. Mas nem tanto (e tenho dúvidas, às vezes). Bom isso é outra discussão.
Quanto ao artigo, não é possível comparar a API do Swing com um JFace, nem a java.util.prefs com o Preferences Framework do Eclipse. Isso é ridículo.
Concordo que a comunidade Swing carece de uma integração (que deve vir por parte da Sun) para construção de um framework de mais alto nível, com suporte a coisas simples, como construção de Wizards, janelas arrastáveis, agendamento de tarefas e outras coisas mais; todas prontas no framework Eclipse. Entretanto, isso não faz parte do Swing e, portanto, não pode ser comparado.
Acredito que o advento do Eclipse (foi em 2001, isso?) foi como graxa na engrenagem para quem usa Swing. A Sun apostou muito na Web, com as JSPs (e toda a tralha de JSRs associadas) e no Java como middleware, com os EJBs. Nesse cenário, o Swing ficou em segundo plano, apenas na correção de bugs.
Agora com o Java 6 o Swing ganhou algumas melhorias, como o suporte à famosa barra de tarefas. Mas foi só.
O pessoal do Netbeans tá se puxando com o desenvolvimento de soluções de alto nível, tal como existe no Eclipse, mas ainda não está perto, infelizmente. O suporte ao arraste de janelas, padronização de operações, suporte a plugins e a estruturação geral do projeto ainda é bem melhor no Eclipse que no Netbeans.
Mas a engrenagem está girando e agora com ela azeitada, as coisas devem seguir bem mais rápido.
Espero sinceramente que surja logo algo como o Eclipse Framework para o Swing. Nada de coisas como o Jide, o InfoNode ou o rudimentar FlexDoc, mas sim uma coisa prática, fácil de usar e disponível no próprio JDK. Talvez tenhamos que esperar uma JSR, mas isso demora.
Termino dizendo que o sr. Amin foi infeliz no artigo que escreveu e que, embora o Swing tenha limitações, podemos estendê-lo com outros produtos e, daí sim, compará-lo de igual para igual com o Eclipse.
Pelo que minha pequena mente percebe, o sr. Amin faz uma comparação entre o Swing e o framework do Eclipse. Daí é Davi contra Golias e isso não serve.
Comparar uma API contra um framework não tem sentido algum. O Swing é uma ótima API MVC, com recursos escaláveis, flexíveis, robusta, estável e com bom (ainda não ótimo) suporte para look and feel. Tem mais coisas, mas isso basta. O SWT é uma contrapartida da IBM que objetiva maior facilidade de desenvolvimento (e por isso seu modelo MVC não é completo), performance mais elevada e comportamento nativo. Na prática, até que me provem o contrário, o SWT é o seguinte: se o controle existe no Sistema Operacional, então o SWT usa ele (tal como o AWT faz o conceito de peered controls); se o controle não existe no SO, então o SWT renderiza ele totalmente (via API 2D) na forma mais parecida com o controle nativo. É do comportamento peered do SWT que surge a necessidade de uma DLL no Windows ou uma SO no Linux para seu funcionamento.
O Swing renderiza tudo sempre. E por isso dizem que ele é mais lento. Mas nem tanto (e tenho dúvidas, às vezes). Bom isso é outra discussão.
Quanto ao artigo, não é possível comparar a API do Swing com um JFace, nem a java.util.prefs com o Preferences Framework do Eclipse. Isso é ridículo.
Concordo que a comunidade Swing carece de uma integração (que deve vir por parte da Sun) para construção de um framework de mais alto nível, com suporte a coisas simples, como construção de Wizards, janelas arrastáveis, agendamento de tarefas e outras coisas mais; todas prontas no framework Eclipse. Entretanto, isso não faz parte do Swing e, portanto, não pode ser comparado.
Acredito que o advento do Eclipse (foi em 2001, isso?) foi como graxa na engrenagem para quem usa Swing. A Sun apostou muito na Web, com as JSPs (e toda a tralha de JSRs associadas) e no Java como middleware, com os EJBs. Nesse cenário, o Swing ficou em segundo plano, apenas na correção de bugs.
Agora com o Java 6 o Swing ganhou algumas melhorias, como o suporte à famosa barra de tarefas. Mas foi só.
O pessoal do Netbeans tá se puxando com o desenvolvimento de soluções de alto nível, tal como existe no Eclipse, mas ainda não está perto, infelizmente. O suporte ao arraste de janelas, padronização de operações, suporte a plugins e a estruturação geral do projeto ainda é bem melhor no Eclipse que no Netbeans.
Mas a engrenagem está girando e agora com ela azeitada, as coisas devem seguir bem mais rápido.
Espero sinceramente que surja logo algo como o Eclipse Framework para o Swing. Nada de coisas como o Jide, o InfoNode ou o rudimentar FlexDoc, mas sim uma coisa prática, fácil de usar e disponível no próprio JDK. Talvez tenhamos que esperar uma JSR, mas isso demora.
Termino dizendo que o sr. Amin foi infeliz no artigo que escreveu e que, embora o Swing tenha limitações, podemos estendê-lo com outros produtos e, daí sim, compará-lo de igual para igual com o Eclipse.
0 comentários:
Postar um comentário