artigo java magazine 53 - Eclipse x NetBeans

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)  (1)

Uma comparação pé-no-chão das duas ferramentas mais usadas por desenvolvedores Java: da filosofia de cada produto às pequenas diferenças práticas.

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

Eclipse x NetBeans

Comparando os grandes IDEs open source

Uma comparação pé-no-chão das duas ferramentas mais usadas por desenvolvedores Java: da filosofia de cada produto às pequenas diferenças práticas

 

Para quem usa e acompanha IDEs Java, o ano de 2007 foi excepcional. Considerando apenas os produtos mais populares, tanto o Eclipse 3.3 “Europa” quanto o NetBeans 6.0 foram atualizações de grande importância. Nesse contexto, o leitor ainda indeciso poderá perguntar: enfim, qual é o melhor IDE? Mas não há uma resposta simples. Ambos os softwares são muito grandes e multifacetados.

Uma comparação no estilo “checklist”, batendo funcionalidade com funcionalidade, poderia dar respostas para perguntas mais granulares, como qual IDE tem o melhor depurador, o melhor editor de JSP, a melhor integração com servidores de aplicações e assim por diante. Esse tipo de comparação, no entanto, tem valor no máximo provisório. Por exemplo, há um ano poderíamos apontar para a grande superioridade do editor de código do Eclipse; mas o NetBeans 6.0 recuperou o atraso nesta área, com um editor totalmente renovado. Da mesma forma, o NetBeans costumava estar muito à frente no suporte a Java EE, mas o Eclipse 3.3 (com o WTP 2.0) também correu atrás do prejuízo.

A escolha do IDE é um investimento de longo prazo; é uma ferramenta que demanda meses para ser dominada. E pouca gente troca de IDE a cada semestre, só por que um competidor deu um passo à frente e se tornou “o melhor” por um breve período. Você abandona o seu time de futebol só porque não venceu o campeonato deste ano?

A proposta deste artigo é comparar o NetBeans com o Eclipse, mas com uma abordagem voltada às diferenças fundamentais – de design, de arquitetura ou de “espírito” – entre os dois produtos. Estas diferenças, na maioria das vezes, não são do tipo que permita um julgamento entre Certo ou Errado, Melhor ou Pior. Porém, será fácil ver que elas permitem a cada leitor – e talvez, para cada empresa ou projeto – decidir qual IDE é mais adequado. Um IDE é uma das principais ferramentas de trabalho do desenvolvedor, e o IDE perfeito é aquele que se adapta à cultura do desenvolvedor: sua metodologia de trabalho, seu ambiente, outras ferramentas preferidas, e até suas manias e valores.

Software Livre ou Proprietário?

O tema do software livre/open source continua crescendo em relevância. Para usuários comuns, o software livre de desktop tem crescido de forma lenta e ainda luta para conquistar espaço. Mas entre os desenvolvedores, não há dúvida que já existe uma grande preferência pelo software livre (embora esta preferência também não seja unânime, certamente prevalece entre os que optaram pelo Java: uma plataforma portável, aberta e, finalmente, também livre).

Tanto o Eclipse quanto o NetBeans posam de “campeões” do software livre, mas como veremos, cada um destes IDEs possui um histórico e um status diferente nesta área.

Eclipse

Os usuários mais antigos do Eclipse lembrarão o seu lançamento, anunciado pela IBM como uma doação à comunidade de US$ 40 milhões – o custo de desenvolvimento do Eclipse 1.0, entre 1999 e 2001. Isso é realmente impressionante, mas também mascara o fato que o Eclipse foi desenvolvido sob portas fechadas até o release 1.0. É comum que isso aconteça em projetos livres patrocinados por grandes corporações: estas esperam até que o projeto atinja um “ponto sem volta”, no qual a maturidade do software garanta a preservação das suas principais decisões arquiteturais.

Um exemplo concreto é o SWT, o toolkit de GUI que até hoje causa polêmica. Se o Eclipse fosse aberto desde o começo, alguém poderia ter decidido fazer uma versão que usasse o Swing. Não seria pouco trabalho, mas seria viável: um esforço incremental, acompanhando o trunk do Eclipse. Mas o código só foi aberto quando o Eclipse 1.0 já estava pronto, incorporando dois anos de trabalho (1999-2001) – e já era muito código. Os fãs do Swing começariam o fork com um enorme atraso, correndo atrás de um projeto que já tinha alguns milhões de linhas de código e (na época) uma equipe de 40 desenvolvedores full-time. Quando a conversão do Eclipse 1.0 para Swing fosse finalizada, certamente já estaria sendo lançando o Eclipse 2.0 ou talvez até o 3.0. E os usuários que precisassem das melhorias mais recentes condenariam o fork baseado em Swing ao ostracismo.

Essa tática não é exclusividade da IBM; aliás, está se popularizando. Outro exemplo recente é o Google Android, nova plataforma para smartphones baseada em Linux e em Java (mas não em Java ME). O Google alardeia que o Android será open source, mas note o “será”: o SDK disponibilizado em novembro de 2007 não vem com os fontes, que só serão liberados no final de 2008, com o Android 1.0 pronto e os primeiros produtos já no mercado. A essa altura, o Android já estará bem maduro; já existirão montes de ferramentas, dezenas de fabricantes já terão feito os portes para seus hardwares. Qualquer mudança fundamental, por exemplo em APIs, causaria quebra de compatibilidade com tudo isso. Assim, o Google também poderá se posicionar de grande defensor do código livre, enquanto exerce firme controle sobre a tecnologia. Mesmo que versões futuras venham a ser desenvolvidas de forma mais aberta pela Open Handset Alliance, não poderão desviar da direção escolhida pelo Google. (Veja mais sobre o Android na coluna “Wireless Update” desta edição.)

No lado positivo, o Eclipse por muito tempo foi visto como o IDE Java mais adequado a sistemas livres. Isso aconteceu devido a dois fatores:

·       A CPL (e depois EPL), licenças open source permissivas e bem aceitas pela comunidade, em especial mais bem aceitas que as licenças da Sun (mesmo a CDDL do NetBeans pré-6.0).

·       O uso do SWT, que contornava deficiências do Swing em sistemas livres.

 

Este último fator vale explicação. Em sistemas como Linux e FreeBSD, as implementações livres de Java (como GCJ e Kaffe) durante muitos anos não foram capazes de rodar programas com interfaces gráficas complexas feitas com Swing. Mas conseguiam rodar bem o SWT, que (ao contrário do Swing) era open source, permitindo à comunidade contribuir portes e correções. OSwing só viria a ter esta vantagem com o recente release GPL, somente em maio de 20071. Por isso, a penetração do Eclipse tem sido bem mais rápida em distribuições de sistemas livres. A última novidade é o Red Hat Developer Studio, novo IDE baseado no Eclipse e em projetos em volta do JBoss-IDE. O Studio, sendo fornecido pela Red Hat, legitimiza ainda mais o Eclipse junto à grande comunidade de adeptos do Linux.

Um último aspecto importante é o controle do desenvolvimento. O Eclipse é guiado pela Eclipse Software Foundation (ESF), uma organização independente, a princípio livre do comando da IBM. A ESF, porém, é sustentada por contribuições dos seus membros (em dinheiro ou em desenvolvedores), portanto essa independência é parcial. Grandes empresas podem contribuir mais, e assim acabam tendo mais committers e mais influência, mesmo quando é assumida uma estrutura perfeitamente meritocrática. Mas isso ocorre em maior ou menor grau com qualquer projeto open source de grande porte.



1 O projeto OpenJDK foi disparado no final de 2006, mas somente nesta data a maior parte do código-fonte do OpenJDK, inclusive a Swing e adjacências (AWT, Java2D) foi disponibilizado.

 

NetBeans"

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?