Quando escrevi o artigo "Por dentro do Eclipse" (Edição 23), o Eclipse 3.1 ainda demoraria um pouco até o release final. Após 16 meses, quando você estiver lendo esta edição, o release final do novo Eclipse – o 3.2 – já estará pronto. Para a maioria dos desenvolvedores, chegou de novo a hora de avaliar um major update da sua principal ferramenta de trabalho.
Eu disse maioria? Segundo estudos recentes [1], o Eclipse goza de uma liderança folgada, mesmo contando somente a distribuição open source. Entre os concorrentes, os produtos da IBM já são baseados no Eclipse, os da Oracle, BEA e Borland vão pelo mesmo caminho, e o IntelliJ IDEA não supera números modestos há anos.
Hoje, o maior concorrente é outro IDE open source: o NetBeans, que apesar da fatia menor de mercado, tem sido um forte desafio, inovando em áreas como desenvolvimento Swing (com o construtor de telas Matisse) e Profiling, e saindo à frente do Eclipse em suporte integrado às plataformas JEE e JME. A Sun tem se tornado ainda mais agressiva recentemente, doando ao NetBeans ferramentas "Enterprise" antes só disponíveis nos seus IDEs comerciais [2]. A disputa entre ambos os projetos tem sido bonita e acirrada. No NetBeans, temos importação de projetos do Eclipse, associações de teclas do Eclipse, e o NetBeans Rich Client Platform para fazer frente ao já popular RCP. Já no MyEclipseIDE (um IDE comercial baseado no Eclipse), existe agora um porte do Matisse. É difícil não admirar esta disputa leal num mercado tão importante e competitivo – sem vestígio de táticas como processos de patentes, exploração de formatos de arquivo, APIs proprietárias etc. Se os projetos Eclipse e NetBeans provam uma coisa juntos, é que o modelo de código aberto força cada projeto a competir satisfazendo o usuário, e oferecendo cada vez mais funcionalidades e qualidade.
Mas voltando ao assunto principal, neste artigo apresentaremos o novo Eclipse 3.2. Novas funcionalidades individuais são bem ilustradas pelos já famosos relatórios "New and Noteworthy" do projeto Eclipse, mas pode ser difícil ter uma visão rápida dos avanços mais importantes, e das conseqüências globais de várias melhorias. Neste artigo, tentamos oferecer esta visão, nos concentrando numa classificação das 10 principais novidades ou melhorias do novo release.
10. Suporte a JUnit 4
Como sabemos, o JUnit é a principal ferramenta de testes unitários para Java (apesar da recente competição com o TestNG); seu suporte integrado no Eclipse é excelente e certamente sempre será. Ocorre que ambos os projetos são "parentes de sangue": o JUnit foi criado por Kent Beck e Erich Gamma, e Gamma também é um dos principais arquitetos do Eclipse, sendo líder do projeto JDT.
O release recente do JUnit 4 é uma importante melhoria deste framework de testes, permitindo a escrita ainda mais fácil de testes unitários, ao substituir a necessidade de herdar de classes como TestCase ou de seguir convenções como criar métodos iniciados por "test", pelo novo recurso de anotações do Java 5. A Listagem 1 mostra um exemplo de teste unitário criado com a nova versão do JUnit. Note que só precisamos aplicar a anotação @Test aos métodos que são testes unitários. Existem mais anotações, para métodos "before/after" e outras necessidades. Veja também que, como não precisamos estender a classe TestCase, podemos usar a sintaxe import static do Java 5 para que seja possível invocar métodos como assertTrue() (que é um método static da classe Assert) de forma direta. O resultado é que você pode escrever testes unitários com bem menos código do que antes.
import static org.junit.Assert.*;
import org.junit.Test;
public class TestJUnit4 {
@Test public void meuPrimeiroTeste () {
assertTrue("Adição", 2 + 2 == 4);
}
}
Note que a API do JUnit 4 não é compatível com a versão 3.x, e a nova versão exige o JSE 5+. Mas como o JUnit 3.x coloca suas classes em packages junit.* e o JUnit 4 muda para org.junit.*, pode-se utilizar ambos num mesmo projeto, o que permite uma migração gradual, ou a convivência entre testes unitários mais antigos feitos com o JUnit 3.x, e outros novos feitos com a versão 4.
O suporte a JUnit do Eclipse 3.2 inclui as bibliotecas das duas versões do JUnit, reconhece ambos os tipos de teste, e executa a todos de forma indistinta. Veja um exemplo na Figura 1. É inclusive possível criar test suites misturando testes feitos com ambas as versões (o JUnit 4 tem APIs que permitem isso).
Outra melhoria importante do suporte do Eclipse para JUnit é a possibilidade de executar vários testes concorrentes, o que é muito bom para conseguir paralelismo, especialmente entre testes de longa duração e de baixo consumo de CPU local (como testes que acessam bancos de dados).
9. Escalabilidade e controle de complexidade
Alguns desenvolvedores podem ter workspaces enormes, com dezenas de projetos e milhões de linhas de código. Ou, mesmo sem tanto código, podem ter que utilizar um número muito grande de plug-ins. O resultado acaba sendo uma grande confusão. O design de Perspectivas, que vem desde o Eclipse 1.0, foi a primeira ação importante no sentido de administrar complexidade, mas como sabemos, o desenvolvimento de software só fica mais complexo a cada ano; assim todas as atualizações do Eclipse têm introduzido novas técnicas para simplificar o ambiente de desenvolvimento.
Filtros
O recurso de filtros em caixas de diálogo, onde um campo no canto superior esquerdo permite excluir todos os itens do diálogo que não contenham a string digitada, foi mais explorado, nos diálogos Show View, New, Import e Export (estas duas últimas agora também são categorizadas). Também se pode filtrar as opções de lançamento (Window > Preferences > Run/Debug > Launching > Launch Configurations). As views de problemas, tasks e bookmarks, que já suportavam filtros, agora aceitam filtros múltiplos (veja a Figura 2).
