Este artigo traz um panorama de projetos open source relacionados com o coração da plataforma Java, e em que tem havido extremos de altos e baixos. Em outubro, o IcedTea liberou sua versão 2.0, baseada no OpenJDK 7, que já está disponível como o Java 7 oficial do Fedora e do Ubuntu Linux; em novembro a Apache anunciou que o Harmony estava sendo rebaixado para o “sótão” da Fundação. São dois exemplos (e dois extremos) de projetos trazendo novidades que poderão afetar o futuro da tecnologia Java, mesmo sem o apoio de gigantes como Oracle e IBM.
IcedTea
Quando a Sun liberou em 2007 os fontes da sua JVM e sua biblioteca de classes, criando o projeto OpenJDK, atual implementação de referência do Java 7, o resultado não era imediatamente usável pela comunidade open source, pois alguns componentes licenciados de terceiros não puderam ser abertos naquele momento. Exemplos de APIs que não foram incluídas no código inicial do OpenJDK são as de gerência de fontes tipográficas e de interação com dispositivos de som. Sem falar de complementos indispensáveis para algumas aplicações, como o plugin web para Applets e o Java Web Start, que embora sejam parte do produto da Sun e Oracle há tempos, cobrem funcionalidades não-padronizadas como parte do Java SE.
Para remediar esses problemas, a comunidade open source criou, com patrocínio da Red Hat, o projeto IcedTea. O objetivo era substituir os componentes proprietários necessários para compilação e execução do OpenJDK, pelos equivalentes em outros projetos open source, especialmente o projeto GNU Classpath.
Na verdade, já havia conversas entre membros importantes da comunidade open source e da Sun bem antes do lançamento do OpenJDK, e não foi acidente a opção da Sun pela licença GPL, em vez das licenças usadas no Glassfish e no extinto Open Solaris. O objetivo era permitir a mistura de código com o ecossistema do GNU Classpath, baseado na GPL.
Já há alguns anos, as distribuições do Linux incluem binários certificados do IcedTea, mas que são distribuídos usando o nome OpenJDK como parte de um acordo com a Sun para acesso ao TCK, o kit de testes de compatibilidade do Java.
Algumas distribuições ofereciam como alternativa o Java proprietário da Sun, empacotado nos repositórios “não-livres”, usando a licença DLJ (Operating System Distribution License for Java). Mas a DLJ foi descontinuada pela Oracle com a liberação do Java 7, não apenas para o novo Java mas também para as versões anteriores. Por isso o IcedTea se tornou o único Java certificado a ser fornecido como parte dos sistemas Fedora, Ubuntu e Debian, além de se tornar também o preferencial para uso em distribuições comerciais com RHEL e SuSE.
O escopo do projeto IcedTea aumentou desde a sua criação. Ele implementou melhorias sobre o OpenJDK, para melhor compatibilidade com o Linux, por exemplo o suporte ao PulseAudio para multimídia; e evoluiu para uso de JVMs alternativas, como a JamVM, entrando no lugar do HotSpot do OpenJDK original.
Ampliando o alcance do OpenJDK
A maior contribuição do IcedTea para o OpenJDK provavelmente foi os projetos Zero e Shark. O Zero é um interpretador genérico de alta performance, que torna o OpenJDK viável em várias plataformas embarcadas, em que o custo de memória e bateria de um compilador JIT seria proibitivo.
Já o Shark utiliza a infraestrutura do LLVM para criar um compilador JIT portável para múltiplas arquiteturas de CPU, evitando a necessidade de se escrever um novo JIT para cada arquitetura de processador. Graças a estes projetos o OpenJDK vem se tornando a implementação do Java preferencial em algumas CPUs populares em plataformas voltadas para a computação embarcadas, como ARM e MIPS.
Note que o IcedTea não é um fork do OpenJDK. Alguns dos seus contribuidores estão no Community Board do OpenJDK e vários dos patches do projeto migraram para o OpenJDK e se tornaram parte do Java 7 oficial.
Outra contribuição importante do IcedTea é um processo de compilação mais simples para o OpenJDK, reduzindo a barreira de entrada para potenciais contribuidores. O projeto OpenJDK não fornece binários para nenhuma plataforma, somente fontes. O JDK fornecido pela Oracle à partir dos fontes do OpenJDK usa uma licença proprietária. Mas, graças ao processo simplificado do IcedTea hoje é possível baixar, sob uma licença open source, binários para Windows no site do Open SCG, que é o mesmo grupo responsável pelo porte nativo do PostgreSQL para Windows.
A certificação do Java SE é realizada sobre binários, não sobre fontes, e os binários do IcedTea inclusos no Ubuntu, Fedora e derivados (como RHEL e CentOS) são certificados desde 2009. Mas os binários do OpenJDK 7/IcedTea 2 inclusos nas distribuições do Linux não são certificados ainda, e nem os fornecidos pelo OpenSCG para Windows. Ambas as comunidades estão trabalhando no processo, e estão em busca de patrocinadores.
Ainda há espaço para outras JVMs open source?
A criação do projeto OpenJDK diminuiu o incentivo a continuidade de vários projetos de JVMs open source. O SableVM foi uma das vítimas. O desenvolvimento do GNU Classpath, que fornecia a biblioteca de classes do Java SE para a maioria destes projetos, ficou congelado no Java SE 5, e o venerável Kaffe apenas recentemente voltou a ter atividade, sendo transferido para o Github.
Poderia ser argumentado que não há mais necessidade de outros projetos de JVMs open source, uma vez que a Sun abriu sua implementação, e ainda mais agora que a Oracle oficializou o OpenJDK como a implementação de referência (RI) para o Java 7. A competição trazida por estes projetos foi benéfica porque estimulou a evolução e a abertura do JDK pela Sun, mas qual seu papel no futuro do Java?
Na época o Classpath estava chegando perto do 100% do Java SE 5 e se tornaria certificável. Com dois Javas open source plenamente funcionais (GCJ+Classpath e Apache Harmony) ficaria complicado manter restrições ao TCK do Java SE, e mais importante, o fluxo de caixa originado pelo licensiamento do JDK da Sun para fabricantes de plataformas móveis e embarcadas. A criação do OpenJDK sob licença GPL permitiu unir esforços à comunidade open source, sem abrir o TCK para projetos externos.
Por outro lado, sem projetos open source independentes, deixa-se de explorar alternativas de design para a JVM, que poderiam atender a nichos específicos ou se tornarem importantes em plataformas futuras. O fato de smartphones e tablets atuais em sua maioria ignorarem a plataforma Java SE (e também a Java ME) mostra que essas alternativas podem estar fazendo falta.
Por exemplo, o GCJ, que é parte da suite de compiladores GCC, tem a opção de gerar código nativo (que não necessita de uma JVM para executar). Era uma opção interessante para aplicações desktop e sistemas embarcados, tanto que foi utilizado pelo RHEL e pela comunidade Fedora para suportar o Eclipse e o Tomcat, antes da criação do OpenJDK. Sem falar na ampla cobertura de arquiteturas de CPU e SOs do GCC, muito superior à suportada pelo Java “oficial” na época.
As releases recentes do GCC continuam suportando o GCJ, e ele continua sendo incluído nas principais distribuições do Linux; mas, infelizmente não parece haver planos para atualizar seu suporte à linguagem Java, nem para completar o GNU Classpath ou atualizá-lo para além do Java 5.
JVMs alternativas ao OpenJDK
O OpenJDK, no entanto, não parece ter diminuído o ritmo do JikesRVM, que tem o diferencial de ser escrito quase que inteiramente em Java. Infelizmente ele não tem a pretenção de ser uma JVM para “uso real”, seu objetivo é ser uma plataforma de testes para novos algoritmos internos à JVM para projetos acadêmicos.
Dois dos projetos baseados no GNU Claspath, o JamVM e o Cacao continuam vivos. Eles colaboram com o projeto IcedTea e hoje podem utilizar a biblioteca de classes do OpenJDK em lugar do GNU Classpath, voltando assim a acompanhar a evolução da plataforma oficial. Apesar de os seus releases mais recentes terem mais de um ano, existe grande atividade nos repositórios de código do JamVM e do Cacao, e espera-se para breve novos releases que finalmente atualizarão suas respectivas JVMs para compatibilidade com as novas versões do Java.
Ambos o JamVM e o Cacao são focados em plataformas embarcadas, explorando diferentes designs para componentes da JVM, como o coletor de lixo, o interpretador de bytecodes e o compilador JIT. A comunidade do JamVM afirma, por exemplo, que é possível gerar um executável da sua JVM ocupando menos de 100 Kb.
Java no .NET
Outro projeto de JVM open source que continua vivo e pode ser interessante para alguns nichos é o IKVM, que roda dentro do CLR do .NET ou do Mono, e permite convivência "sem costuras" entre código escrito em Java e código escrito em C#, VB.Net ou outras linguagens que rodam sob o CLR.
O IKVM também permite empacotar aplicações Java como assemblies nativas do .NET. O projeto ganhou certa popularidade entre desenvolvedores que gostariam de continuar tendo acesso a bibliotecas Java em um projeto .NET. É também o projeto mais atualizado em relação aos padrões do Java, pois já oferece um release candidate com suporte ao Java 7.
Com o fim do Harmony, como fica o Android?
A DalvikVM, que é a base das aplicações Android, é baseada na biblioteca de classes do Java SE fornecida como parte do Apache Harmony. Originalmente este projeto tinha apoio da IBM, que contribuiu com a maior parte do código para a biblioteca de classes, mas quando a IBM decidiu focar seus esforços no OpenJDK, o Harmony ficou “órfão”. O projeto Harmony foi oficialmente descontinuado pela Apache Software Foundation em novembro deste ano. Ao contrário do que muitos esperavam, o Google não assumiu o projeto, mantendo o desenvolvimento do Dalvik como um fork separado, provavelmente devido ao processo aberto pela Oracle por violação de patentes.
O Dalvik não é exatamente uma JVM, pois roda seu próprio bytecode, e usa uma arquitetura interna bem diferente da usada no OpenJDK, embora semelhante ao JamVM e ao CacaoVM. O desenvolvimento das aplicações para o Dalvik é feito na linguagem Java, e os bytecodes Java são convertidos em bytecodes Dalvik. Está disponível apenas um subconjunto da API do Java SE, embora maior do que o incluso no Java ME, mas o Dalvilk não traz nada do Java oficial para celulares, sendo incompatível com MIDP ou CDC. Recursos que seriam parte do Java ME são fornecidos por APIs proprietárias para o Android, ou por acesso a serviços do Google.
A omissão do Google quanto ao Harmony dá margem a dúvidas sobre qual será o futuro do “Java” no Android:
- O Google vai continuar evoluindo o Dalvik usando ideias do Java, de modo similar feito pela Microsoft com o .NET?
- A empresa irá focar no desenvolvimento nativo, descontinuando a DalvikVM?
- Ou será o HTML 5 quem poderá provocar um futuro abandono do DalvikVM e Java no Android?
Qualquer que seja o futuro do Dalvilk, ele representa uma linha que poderia ter sido incorporada ao Java oficial e que garantiria a popularidade do Java na computação móvel. A disputa entre Google e Oracle não atende aos interesses da comunidade Java, e a recente ênfase no HTML 5 mostra bem como o mercado ainda carece de uma solução para desenvolvimento interoperável entre smartphones e tablets de diferentes fornecedores.
Serviços nativos do Linux
O exemplo do Dalvik mostra que, apesar da necessidade de funcionalidades independentes de plataforma, há também necessidade de se incorporar suporte a recursos nativos. O Java 7 já foi uma evolução nessa direção, com a nova API de filesystem do NIO2 e se pode argumentar que o Eclipse deve grande parte do seu sucesso ao toolkit gráfico SWT, também baseado no acesso a recursos nativos de Windows, Unix e Mac.
Novamente vemos que a comunidade open source traz novidades neste sentido, dentro do ramo da computação embarcada. Por exemplo, o BUG System e o OpenEmbedded fazem uso de APIs Java para acesso ao desktop Gnome e o D-Bus – efetivamente colocando o Java em pé de igualdade com o código nativo, no acesso aos recursos do SO e Desktop do Linux.
Em vez de criar todo um “universo paralelo”, como feito pelo Android, estes projetos buscam maximizar a utilidade de recursos já conhecidos dos desenvolvedores em plataformas embarcadas, e abrem espaço para a plataforma Java como “linguagem de sistema” para o Linux, viabilizando o desenvolvimento de aplicações de gerência de hardware sem recorrer diretamente a código nativo.
Conclusões
Podemos ver que, apesar do foco de grandes empresas no projeto OpenJDK, ainda há vários outros projetos open source com potencial de contribuir para a evolução da plataforma, especialmente em nichos ainda negligenciados pela plataforma oficial, como o de dispositivos embarcados. Vale a pena acompanhar o amadurecimento destes projetos, pois de um deles pode sair o diferencial competitivo para os produtos da sua empresa, ou surgirem evoluções importantes para a plataforma oficial do Java.