Quando nos referimos a JVM, runtime Java, JRE, JDK/JSDK etc. quase sempre estamos falando de uma implementação específica do J2SE, a da Sun Microsystems. Mas existem diversas outras implementações. As alternativas mais importantes são as certificadas como 100% compatíveis com as especificações do J2SE, e tendem a ser muito parecidas com a da Sun, de forma a preservar o ideal WORA ("Escreva uma vez, rode em qualquer lugar"). Mas existe uma variedade ainda mais rica de máquinas virtuais Java. Algumas são plataformas de pesquisa, outras seguem uma arquitetura diferente do convencional, ou são projetos open source que apresentam diferentes objetivos e peculiaridades.
Este artigo dedica-se a explorar essas JVMs alternativas, que podem ter atrativos bastante diferentes para cada leitor. Veremos diversos projetos livres e projetos que incorporam novas idéias, em geral estendendo a funcionalidade padrão do J2SE e demonstrando capacidades que um dia poderão aparecer no "Java oficial”.
Nos títulos referentes a cada JVM indicamos entre parênteses a versão do J2SE compatível. E se você está começando a explorar a tecnologia, ou quer verificar como foram padronizadas as principais siglas neste artigo, confira o quadro “As siglas do Java” antes de começar.
Implementações do J2SE
Vamos começar pelas alternativas que têm o direito de usar o nome e a logomarca “Java”. São todas comerciais e todas derivadas, pelo menos em parte, do código da implementação da Sun. Isso torna estas alternativas muito homogêneas – costumam possuir até mesmo muitos bugs idênticos aos do Sun JDK, uma vez que reusam seu código.
As empresas que licenciam a plataforma J2SE têm acesso ao código fonte do J2SE da Sun, podendo modificar estes fontes e distribuir suas modificações. Mas o grau efetivo de modificações varia de um licenciado para outro. Boa parte das empresas limita-se a portar o código para suas próprias plataformas (por exemplo, a HP faz isso para o HP-UX). Mas a IBM, BEA e Apple são exceções, fazendo alterações significativas a partir do JDK da Sun.
(1.4.2) IBM JDK: ibm.com/developerworks/java/jdk
O IBM JDK substitui o HotSpot (a máquina virtual da Sun) por uma JVM totalmente nova. Substitui também algumas APIs críticas por implementações da IBM – especialmente as de CORBA e segurança. Também faz algumas alterações em várias APIs implementadas pela Sun.
O IBM JDK é distribuído primariamente como parte do WebSphere Application Server, mas também pode ser obtido gratuitamente. Na distribuição para Windows, a IBM sempre inclui o JDK em algum pacote maior. A versão 1.4.2, por exemplo, está embutida no “IBM Development Package for Eclipse”. Se você não usa o Eclipse, pode baixar este pacote, extrair o IBM JDK e apagar o resto. Antes de enfrentar o download de mais de 80 Mb, é bom saber que a licença não permite a redistribuição, o que dificulta o uso do IBM JDK para fins comerciais. A IBM também oferece um JRE (46 Mb), mas com a restrição de que só pode ser usado legalmente em computadores fabricados pela IBM (nem instalará em máquinas de outros fabricantes).
O JDK da IBM inclui duas JVMs distintas. A JVM padrão é otimizada para servidores. A segunda, que é acionada com a opção –Xj9, é a J9, uma máquina virtual Java para plataformas leves (incluindo o J2ME). A versão da J9 incluída no IBM JDK suporta toda a funcionalidade do J2SE, e suas vantagens são um menor tempo de carregamento e consumo de memória mais baixo. Comparando com o JDK da Sun, a JVM padrão do JDK da IBM equivale ao HotSpot Server, e a J9 equivale ao HotSpot Client.
Para os usuários do Eclipse, o IBM JDK (com a J9) é a opção mais indicada para rodar o próprio Eclipse. Esse JDK é incluído nos IDEs comerciais da IBM baseados no Eclipse, como WSAD e XDE, mas para a distribuição básica do Eclipse, ele deve ser instalado separadamente. Feito isto, basta modificar o atalho ou script de lançamento do Eclipse, adicionando os parâmetros -vm caminho_do_JDK/java.exe –vmargs –Xj9.
(5.0) BEA JRockit: commerce.bea.com/products/weblogicjrockit/5.0/jr_50.jsp
O JRockit da BEA substitui o HotSpot por uma VM inteiramente nova, mas utiliza as APIs da Sun sem modificações. Uma VM totalmente orientada a servidores, a JRockit é otimizada para rodar o WebLogic Server (WLS). Não existem opções favorecendo tempo de carga ou consumo de memória, como o HotSpot Client ou o J9 da IBM.
O JRockit foi desenvolvido inicialmente por uma empresa sueca, a Appeal, e é uma JVM comercial. A BEA Systems adquiriu a empresa para ter a sua própria JVM e fez otimizações para o WLS. Mas posteriormente o JRockit foi tornado disponível gratuitamente para uso geral (inclusive comercial).
Outra vantagem interessante do JRockit é a sua capacidade de selecionar dinamicamente o algoritmo de garbage collection (GC) utilizado pela JVM, com base no comportamento das aplicações. Outras JVMs, como as da Sun e da IBM, também oferecem uma variedade de opções de GC, mas o desenvolvedor precisa configurá-las com switches de inicialização da JVM (ex.: -XX:+UseParallelGC). O JRockit não só seleciona automaticamente estas configurações, mas também é capaz de mudá-las no meio da execução do programa, ao perceber que uma outra opção produziria melhor desempenho.
Em comparação com a IBM, que sempre demora muito para atualizar seu JDK, a BEA tem conseguido acompanhar os releases da Sun bem de perto, o que torna o JRockit uma alternativa viável para qualquer projeto, com ou sem o servidor WebLogic.
Outro extra do JRockit são seus recursos de gerenciamento da JVM, que incluem um console de gerenciamento remoto (veja a Figura 1) e facilidades para detecção de vazamentos de memória. Estes recursos deixaram de ser um grande diferencial a partir do J2SE 5.0 (veja o artigo “Gerenciamento em Java”, Edição 21), mas ainda são atraentes para quem precisa se limitar à versão 1.4.2. (Além disso, a licença de uso gratuito do JRockit não inclui os recursos de gerenciamento, permitindo somente avaliá-los, sem ter uma licença comercial.)
(1.4.2) Apple J2SE: developer.apple.com/java/download
A máquina virtual da Apple utiliza tanto o HotSpot quanto as APIs da Sun, mas com melhorias. A Apple aperfeiçoou o HotSpot para compartilhar código entre diversos processos. (Esta melhoria serviu como base para a facilidade de CDS (Class Data Sharing) do J2SE 5.0 da Sun.) Quanto às APIs, a AWT e a Swing foram customizadas para maior integração e desempenho com a interface gráfica do Mac OS X e suas APIs nativas (Quartz, Carbon). Assim, a plataforma da Apple foi a primeira a obter Java com look-and-feel perfeito. Além disso, o Mac OS X é o único sistema operacional "de massa" que é distribuído com o JDK já incluído.
Diferentemente da IBM e BEA, a Apple não é um vendedor de soluções J2EE, mas ainda assim tem feito um grande esforço para oferecer bom suporte para Java, o que só beneficia o Mac OS: a portabilidade das aplicações Java facilita a mudança para o Mac.
A Apple também oferece diversas APIs proprietárias que permitem aos programadores explorar recursos exclusivos do Mac OS; mas felizmente são extensões “limpas”, pois a Apple não remove ou altera nenhuma API pública do J2SE. Dessa maneira, qualquer programa puro-Java irá rodar perfeitamente no Mac.
Quanto à licença do J2SE da Apple, não há restrições. Mas há naturalmente uma amarração com o sistema operacional. Atualizações do J2RE da Apple são incluídas em atualizações do Mac OS X, as quais costumam ser cobradas. O JDK 5.0 estará disponível na próxima versão do Mac OS X (a versão 10.4, que coincidentemente também leva o codinome “Tiger” e deve estar disponível quando esta edição estiver nas bancas).
(5.0) JET: excelsior-usa.com/jetdl.html
Produto da Excelsior LLC, o JET desvia da modalidade mais comum de implementação do J2SE – a VM totalmente dinâmica – e implementa o Java com compilação estática. O JET converte código Java (fontes .java ou bytecodes .class/.jar) em código nativo (.exe/.dll), executável diretamente pelo sistema operacional. São suportados Windows e Linux.
Como esse modelo de deployment é incompatível com as funcionalidades mais dinâmicas do Java, o runtime do JET também inclui uma VM com um compilador JIT, com capacidade de carregar classes dinamicamente e executá-las. Assim, apesar de ser primariamente um compilador estático, o JET é certificado compatível com o J2SE. Veja o quadro “Compiladores estáticos para Java”.
A Excelsior não licencia o J2SE da Sun e não usou nenhum código do Sun JDK no JET. Ainda assim, depende das APIs da Sun. O instalador do JET exige o JRE, fazendo uma pré-compilação de todas as APIs para posterior linkagem com cada aplicação. Mesmo com isso, os executáveis gerados (para algumas aplicações, não todas) dependem de certos arquivos do J2RE (como as bibliotecas nativas da AWT, fontes e dados de internacionalização).
O JET é um produto comercial. Costumava haver uma Personal Edition gratuita para uso não-comercial, mas com o release 3.7, isso está sendo revisto. Há downloads de avaliação, mas a Excelsior ainda está decidindo se voltará a disponibilizar alguma versão gratuita. O novo release é o primeiro a suportar o J2SE 5.0 e introduz novas opções de runtime de alta escalabilidade (ainda assim, me parece arriscado restringir a distribuição gratuita, num mercado lotado de JVMs grátis de alto desempenho).
(1.4.2) Blackdown: blackdown.org
A Sun começou a suportar a plataforma Linux apenas com o Java 2 e mesmo hoje, não suporta todas as variantes do Linux. O grupo Blackdown formou-se para resolver este problema. A Sun deu acesso privilegiado aos seus fontes para o grupo, que produziu versões para Linux do JRE/JDK e das APIs que exigem porte por usarem código nativo, como Java3D, JAI (Java Advanced Imaging) e JMF (Java Media Framework). Estão disponíveis builds do J2SE das versões 1.0.2 até 1.4.2, mas somente em distribuição binária (sem fontes). A versão para J2SE 5.0 está em desenvolvimento. Além de portar o código para conseguir compilar no Linux, o grupo Blackdown também implementou muitas otimizações, por exemplo nas bibliotecas de threads ou I/O do Java, de maneira a funcionar com maior eficiência no Linux.
...
