Artigo Java Magazine 47 - Eclipse 3.3

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (0)  (0)

Artigo publicado pela Java Magazine 47.

Esse artigo faz parte da revista Java Magazine edição 47. Clique aqui para ler todos os artigos desta edição

Eclipse 3.3

Conheça o que há de novo no núcleo do IDE e da Plataforma

O essencial do que mudou nas partes fundamentais do Eclipse, e detalhes sobre algumas tecnologias que diferenciam o projeto, como a SWT

Chegamos a outro mês de junho e, como já é tradicional, a outro release do IDE Eclipse. Na Edição 37, conhecemos o projeto Callisto, desenvolvimento coordenado do Eclipse 3.2 com um grande número de complementos hoje considerados essenciais. Dando continuidade a este plano, o satélite da vez é o Europa. Imagino se os próximos releases serão Io e Ganymede?[1] Mas como a revista é de software e não de astronomia, vamos deixar essa especulação de lado e examinar as novidades e aperfeiçoamentos do IDE mais usado pela comunidade Java.

Porém, antes de realmente começar, algumas palavras sobre este artigo. Todo ano escrevo sobre o novo Eclipse, e é difícil “encaixar” centenas de novidades (mais discussões de tecnologias e assuntos relevantes) em poucas páginas. Procuro evitar uma repetição de informações presentes no site eclipse.org, como os relatórios New and Noteworthy. Minha intenção aqui é favorecer conteúdo novo e importante.

Decidi, dessa vez, eliminar por completo qualquer apresentação de melhorias superficiais. Assim, você não encontrará aqui nem uma única informação como:

§         “A GUI está mais bonita: abas de views desabilitadas têm cantos com curvas...”

§         “No depurador, o Step Into numa expressão complexa é mais fácil: segure Ctrl+Alt e...”

§         “O diálogo de configuração de associações de teclas a comandos foi melhorado...”

 

Sim, o Eclipse 3.3 tem um enorme número de melhorias desse tipo, que tornam funcionalidades preexistentes mais fáceis de usar, mais organizadas, agradáveis, produtivas, completas. Mas aqui teremos que deixar de lado estes itens “decorativos” ou mesmo incrementais. Cobriremos somente as novas funcionalidades. Exceção apenas para melhorias críticas na facilidade de uso, como os novos refactorings “inline”. Para as minúcias, remetemos o leitor aos relatórios New and Noteworthy (cujos links estão disponíveis nas páginas de download de milestones e de versões finais do Eclipse).

Aproveitaremos o espaço aberto por esta abordagem, para não só falar das novidades desta versão, mas também para discorrer sobre tópicos interessantes e atuais ligados ao Eclipse. Por exemplo, daremos uma atenção especial à SWT, assunto importante para desenvolvedores que usam o Eclipse RCP (Rich Client Platform).

A evolução do Eclipse

O produto principal da Fundação Eclipse, o JDT (Java Development Tools[2]) teve desde o começo uma excelente reputação, oferecendo um editor de código e gerenciador de projetos excepcionais, um compilador com capacidades inéditas (incremental e integrado às funcionalidades do IDE como editor ou refactorings), uma arquitetura de plug-ins sofisticada e extensível, um novo toolkit de GUI considerado na época superior ao Swing... Por esse resumo podemos ver que desde o começo o projeto Eclipse não se limitou ao IDE. Para mais detalhes, veja o quadro “Eclipse: o IDE e a tecnologia”. 

Nota 1: São os nomes dos satélites “galileanos” de Júpiter: os quatro maiores, descobertos por Galileu em 1610.

Nota 2: Também conhecido como “Eclipse IDE” ou simplesmente “Eclipse”, termos potencialmente ambíguos, mas que utilizaremos aqui dessa maneira para não complicar

Por outro lado, o Eclipse era pobre na cobertura de técnicas especializadas de desenvolvimento. Não tinha editores visuais de GUI, suporte a J2EE/Java EE, nem coisas bem mais básicas como um editor de XML. Embora a sua ampla comunidade de desenvolvedores de plug-ins garantisse que nenhuma necessidade ficaria sem suporte, é bom ter plug-ins de terceiros, mas não é bom depender somente deles.

Recursos incorporados aos projetos oficiais da Fundação Eclipse são quase sempre muito superiores aos produzidos por terceiros (a maioria das exceções são produtos comerciais). Criar ferramentas de desenvolvimento modernas exige muitos recursos. Indivíduos ou projetos open source pequenos e sem patrocínio têm pouca chance de competir com equipes grandes, bem estruturadas e sem dúvida bem pagas pela multidão de grandes corporações que sustentam a Fundação Eclipse[3].

Há cerca de um ano, com o Callisto, parecia que o Eclipse recuperaria todo o atraso em relação a outros IDEs na abrangência de ferramentas. Mas o mundo não ficou parado enquanto o Eclipse corria atrás de funcionalidades como criação de JSPs e EJBs. Assim, quando o WTP (Web Tools Project) 1.x chegou, a primeira reação pode ter sido de satisfação com as funcionalidades disponíveis. Mas a segunda poderia ser: OK, temos o feijão-com-arroz do J2EE 1.4, mas cadê o resto? Suporte a Struts, JSF, edição visual de GUIs, mapeamento objeto-relacional, e mesmo suporte a Java EE 5 e JPA/EJB 3 (na época ainda em desenvolvimento, mas já contando com suporte inicial de outros IDEs)?

O WTP continuou atrás da competição, especialmente após o NetBeans Enterprise Pack 5.5. E se o suporte para Java EE ainda não era ideal, o que dizer do Java ME, até há pouco sem absolutamente nenhum suporte? Teríamos, então, que esperar mais uma geração da família de ferramentas Eclipse para atingir um status de estado da arte em todas as funcionalidades agora consideradas essenciais.

O Europa ou Eclipse 3.3 traz grandes atualizações nessas áreas anteriormente defasadas. Veremos se estas melhorias foram suficientes ao longo deste ano, pois o presente artigo é focado apenas no JDT. Aguarde por edições futuras da Java Magazine, onde teremos artigos mais específicos abordando as novidades do WTP e de outras ferramentas do Europa (mas mencionaremos brevemente algumas destas novidades aqui).

Aqui estamos falando do núcleo do Eclipse, que mesmo na liderança, também não ficou repousando sobre suas glórias e continua avançando. Há muitos aperfeiçoamentos na versão 3.3. São coisas cada vez mais evolucionárias, que tornam os recursos que já existiam melhores e mais refinados, ou acrescentam novos recursos cada vez mais discretos. Mas isso não significa que o update não valha a pena. Pelo contrário, o acúmulo de muitos “toques sutis” pode fazer a diferença entre uma ferramenta ótima e uma excepcional – mais inteligente, eficiente e ergonômica.

SWT

A SWT, o toolkit de GUI que compete com os padrões do Java (AWT/Swing/Java 2D), continua firme e forte apesar de toda a reclamação da Sun ou do grande avanço da Swing no Java SE 6 (e fora dele, com Bean Binding, Swing Framework, NetBeans Platform etc.). No release 3.3, o foco foi de suporte cada vez melhor a um número maior de plataformas. Há melhorias para todos: impressão no GTK, suporte ao System Tray do Mac OS X, cursores coloridos em ambos, e novos recursos em geral como um componente de calendário.

Não é possível ignorar, todavia, que o Windows continua sendo o sistema operacional instalado em 90% dos PCs. E que o grande lançamento do ano foi o Windows Vista, cuja GUI estabelece o alvo que toda a indústria de software para PC irá perseguir a partir de agora. O Vista tem uma nova infra-estrutura gráfica que quebra uma tradição de 22 anos, tornando obsoleta a GDI (API gráfica fundamental do Windows – do 1.0 até o XP) e substituindo-a por algo radicalmente novo.

Aí entra a SWT 3.3. Esta nova versão do polêmico toolkit gráfico da Fundação Eclipse possui um novo porte: a SWT para WPF (WPF é o novo framework gráfico do .NET 3.0 / Windows Vista[4]). Então você, criador de aplicações ricas em Java, que já instalou o Vista e se informou sobre estas novidades já prevendo as futuras expectativas dos seus clientes, não precisa mais se desesperar e trocar o Java pelo .NET. Basta usar a SWT e sua aplicação ficará totalmente alinhada com o novo padrão de funcionalidade estabelecido pelo Windows Vista.

Ainda não se sabe se a Sun dará suporte semelhante com a Swing, mas isso é bem provável. Senão os adeptos da Swing sofreriam séria desvantagem: a SWT, JFace e Eclipse RCP se tornariam (novamente) muito superiores às APIs padrão para aplicações exigindo o máximo em termos de recursos nativos de GUI. Um porte da Swing para WPF não deve ser difícil, uma vez que a Apple já fez algo parecido na sua plataforma: no JDK da Apple (que é um porte do Sun JDK) para o Mac OS X “Tiger”, a Swing foi “envenenada” com a tecnologia Quartz Extreme, que é comparável à WPF."

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?