Artigo Java Magazine 58 - EclipseCon 2008: Destaques

Novidades deste ano da Fundação Eclipse

A ESF dá uma guinada na direção das tecnologias de runtime, fortalecendo ainda mais a estratégia de ferramentas Eclipse

A Fundação de Software Eclipse (ESF) estabeleceu-se como uma das entidades mais influentes do mundo Java. Embora nem todo desenvolvedor Java prefira IDEs baseados no Eclipse (JDT e derivados), os projetos da ESF vão muito além do JDT, tanto no sentido horizontal – como IDEs para outras linguagens, quanto no vertical – componentes em outras categorias. Desde o início de 2007, a ESF também passou a integrar o JCP (Java Community Process), passando a influir de forma direta e oficial na elaboração de diversos padrões formais da plataforma Java. Além disso, o fato da ESF ter entre seus membros diversas organizações de grande influência (como IBM, BEA, Intel, Nokia, Oracle e muitos mais) também garante a sua relevância no mercado.

A demonstração mais impressionante da força da ESF e do Eclipse é, sem dúvida, a existência de uma conferência técnica de grande porte: quatro dias, 300 sessões e mais de 1.300[1] atendentes. Nenhum outro IDE, para qualquer linguagem ou plataforma, consegue um feito similar (embora, para ser justo, a EclipseCon não trate somente do JDT ou outros IDEs.)

Neste artigo, discutimos algumas novidades divulgadas na EclipseCon 2008. O material das apresentações técnicas está disponível gratuitamente na Internet (veja Links); são 230Mb de apresentações. Resumir todo este material num artigo seria tanto superficial quanto redundante; portanto, optei por destacar somente as principais novidades apresentadas na conferência, permitindo assim uma discussão mais aprofundada.

A colaboração ESF + Microsoft

Essa notícia é sem dúvida a mais polêmica da EclipseCon 2008, uma vez que qualquer coisa envolvendo Microsoft e Java é polêmica. Na sua keynote, Sam Ramji, diretor do Open Source Software Lab da Microsoft, anunciou o início de uma colaboração com a ESF, focada no aperfeiçoamento do porte da SWT para a WPF.

Sim, a Microsoft possui um departamento de Open Source – uma iniciativa ainda tímida, vista com desconfiança pela comunidade. Seu objetivo parece ser o de aparar as arestas com o mundo FOSS, pelo menos em questões de benefício mútuo. Seu site Port25 hospeda projetos livres como um plug-in do Windows Media Player para o Firefox, e atualizações do kernel do Linux para otimizar o seu uso dentro do Microsoft Virtual Server.

Não muito atrás no quesito polêmica, a SWT (Standard Widget Toolkit) é o toolkit de GUI da ESF, concorrente direto da trinca AWT / Java2D / Swing do padrão Java SE. A SWT foi o pivô da discórdia entre a Sun e a ESF, sendo o principal motivo pelo qual a Sun não se juntou à Fundação. Já a WPF, Windows Presentation Foundation, é um novo framework gráfico presente no Windows Vista. Uma novidade do Eclipse 3.3, lançado em junho de 2007, foi um novo porte da SWT para a WPF. Este porte implementa a API da SWT em cima da WPF, tornando aplicações SWT cidadãs de primeira classe no Vista, com direito a todos os recursos gráficos avançados deste ambiente. Veja “Eclipse x NetBeans” na Edição 53 para mais informações sobre a SWT para WPF.

O anúncio foi recebido com estranheza por muitas pessoas. Afinal, por que a Microsoft ajudaria a ESF a aperfeiçoar a SWT, uma tecnologia Java? Uma das razões, na minha opinião, é que a adoção da WPF continua avançando a passo de lesma. Quase um ano e meio após o lançamento do Vista, o número de aplicações Windows “tunadas” para explorar a WPF ainda é pífio. Alguns sites que consultei listam poucas dezenas de aplicações, metade delas sendo de sites XBAP (tecnologia RIA baseada na WPF), e não havendo nem uma única aplicação expressiva. Nem mesmo aplicações gráficas importantes da própria Microsoft, como o PowerPoint, foram portadas para a WPF.

Como já opinei na Edição 53, a Microsoft cometeu um erro estratégico ao amarrar a WPF à plataforma .NET. A WPF não possui API Windows convencional (nativa); só pode ser programada em linguagens .NET como C#. Mas a esmagadora maioria das aplicações Windows existentes é escrita em C ou C++, linguagens não suportadas pela .NET. Para aplicações de grande porte, por exemplo um Adobe Photoshop, o porte para a WPF teria um custo colossal.

A .NET suporta “Managed C++”, um dialeto inventado pela Microsoft, que é bastante diferente do C++ padrão e não suporta frameworks do C++ como a MFC. A .NET permite misturar código gerenciado e não-gerenciado na mesma aplicação, mas isso cria suas próprias complicações.

Dou este exemplo porque a Adobe recém anunciou que o Photoshop CS4 terá uma versão de 64 bits, mas só para Windows, pois no Mac, as APIs legadas do OS9 (Carbon) não estão disponíveis em 64 bits, e a Adobe nunca migrou para as novas APIs do OSX (Cocoa). Esta migração exigiria revisar ou reescrever cerca de um milhão de linhas de código. Isso não é o Photoshop inteiro... só a parte que interage com o toolkit gráfico. E este porte seria bem mais fácil do que um porte similar da Win32 para a WPF – por exemplo, não exigiria mudar a linguagem de programação.

É nesse ponto que a SWT entra. Apesar de todas as críticas que o Java recebe no Desktop, há muito mais aplicações desktop escritas em Java do que em WPF. Mas com a SWT/WPF, todas as aplicações Java/SWT tornam-se aplicações WPF. Mesmo aplicações Swing poderiam ser portadas para a SWT com esforço relativamente pequeno, em comparação com as outras opções. O único inconveniente é que a SWT/WPF exige que a aplicação carregue duas VMs no mesmo processo: a JVM para rodar o código Java, e o CLR (VM da plataforma .NET) somente para o acesso à WPF.

Isso cria um overhead que já medi em 10-15Mb. Talvez possa ser evitado, por exemplo, rodando o código Java numa VM híbrida como o Mono+IKVM, que é compatível com a .NET mas dá suporte a Java. Mas o projeto Mono não implementa (nem planeja implementar) a WPF, o que não é de interesse da comunidade open source (só funcionaria no Windows) e provavelmente não seria possível sem auxílio da Microsoft.

...