Artigo Java Magazine 24 - JVMs Alternativas

Byte Code

JVMs Alternativas

Explore Implementações do J2SE

Desde máquinas virtuais comerciais de alto desempenho a projetos de pesquisa e VMs livres, conheça opções de JVMs para uma diversidade de áreas de aplicação

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[1], 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 "