JavaFX Script

Uma nova definição para “linguagem dinâmica”

Uma referência didática da linguagem JavaFX Script, uma das principais peças da plataforma JavaFX

De que se trata o artigo:

Apresentamos uma referência da linguagem JavaFX Script, que faz parte da plataforma JavaFX.

Para que serve:

JavaFX é a nova plataforma RIA da Sun, compatível com Java SE e Java ME, já apresentadas em artigos anteriores desta série. Alguns leitores podem encarar a exigência de aprender uma nova linguagem de programação como um obstáculo, mas este aprendizado é facilitado pela semelhança entre JavaFX Script e Java – tiramos proveito desta semelhança para explicar a nova linguagem de forma concisa. Mesmo para quem já aprendeu JavaFX Script, o artigo serve como uma referência bem organizada e pragmática (ao contrário da referência oficial, que tem uma estrutura mais formal, certamente mais detalhada, mas não adequada à facilidade de consulta e sem pretensões didáticas).

Em que situação o tema é útil:

A linguagem JavaFX Script é um pré-requisito para desenvolver para a plataforma JavaFX, a qual promete grande produtividade, mas (com qualquer plataforma) somente após vencer uma curva inicial de aprendizado.

Mesmo para quem não tiver grande interesse na JavaFX, o artigo apresenta muitas inovações da JavaFX Script que são um aprendizado valioso para qualquer interessado em linguagens de programação.

 

 Na Edição 67 apresentamos a plataforma JavaFX, introduzindo-a de forma conceitual e dando alguns “aperitivos” das suas funcionalidades e programação. Na Edição anterior (68), seguimos com um primeiro tutorial de programação JavaFX, ensinando o básico da linguagem e framework de uma forma prática, mas bastante informal.

Agora, encerrando esta cobertura inicial da JavaFX, vamos nos focar apenas na linguagem JavaFX Script, cobrindo-a de uma forma mais formal e abrangente. (Para o leitor ainda pouco motivado a aprender JavaFX Script, seria boa idéia começar pelo quadro “Por que uma nova linguagem?”.)

Não é meu objetivo repetir o documento de Referência da Linguagem de Programação JavaFX Script que está disponível em openjfx.dev.java.net/langref. Ao invés disso, a idéia é explicar a linguagem de uma forma concisa e pragmática, tendo como alvo não alguém que vai escrever um compilador ou outra ferramenta que exige conhecimento formal da linguagem, mas um desenvolvedor que deseja vencer a curva de aprendizado da sua sintaxe ou então ter uma referência de fácil consulta. Ainda mais especificamente, escrevo pensando no programador que já conhece bem a linguagem Java, o que permitirá resumir ou omitir explicações dos pontos onde ambas as linguagens forem iguais ou muito parecidas (e são muitos pontos). Assim, podemos concentrar nosso tempo e neurônios nas partes que são diferentes.

O artigo é organizado como uma referência da linguagem, agrupando suas funcionalidades em seções como Valores, Operadores, Classes etc., de forma similar a uma referência formal. No entanto, fiz este agrupamento de uma forma “relaxada” segundo critérios conceituais e não de gramática formal. Por exemplo, a seção de Operadores não possui todos os operadores, pois alguns deles são cobertos em outras seções (ex.: os diversos operadores específicos para sequences são mostrados na seção Sequences). Também não me preocupei em documentar minimamente alguns aspectos mais elementares da linguagem que são exatamente idênticos a Java, por exemplo a sintaxe para números literais. A intenção é ter um texto o mais compacto e didático possível, mas ainda assim, suficientemente organizado e formal para servir como referência da linguagem.

Nota: no decorrer do artigo, uso o termo “JavaFX” no lugar de “JavaFX Script”, por simplicidade.

Tipos e Valores

O sistema de tipos da JavaFX é inspirado no Java, mas com melhorias importantes. Na Tabela 1, classifiquei os tipos da JavaFX em cinco categorias e comparei-os aos tipos equivalentes em Java. Vamos comentar apenas as novidades desta tabela.

Valores

A maior novidade é que o typesystem de JavaFX é OO-puro: não existem tipos primitivos. Por outro lado, existem “tipos de valor”, que são aqueles cuja igualdade de referência é equivalente à igualdade de valor (em outras palavras: x == y se e somente se x.equals(y)). Os tipos primitivos do Java, como int, são tipos de valor, por isso não há dois valores 17 distintos, por exemplo. O mesmo vale para o Integer da JavaFX. Além disso, os valores são imutáveis, e não admitem null.

A diferença entre esses tipos da JavaFX e os tipos primitivos do Java é que os tipos de valor são objetos. Em JavaFX, todos os tipos, sem exceção, são derivados de Object.

Em termos de implementação, os valores de JavaFX são equivalentes aos primitivos de Java, evitando o custo de desempenho de usar objetos. Por exemplo, se você olhar o arquivo .class gerado pelo javafxc para uma função que recebe um parâmetro Integer, verá que o bytecode compilado irá conter um método que recebe um int primitivo. Somente quando um valor é utilizado em alguma operação que exige sua faceta OO, a JavaFX faz uma conversão automática para um objeto. Você pode considerar isso uma versão melhorada do autoboxing de Java 5. As melhorias incluem a simplificação (não há tipos paralelos como int/Integer) e desempenho (o compilador, runtime e frameworks usam várias técnicas para representar valores na forma primitiva, e reduzir ao mínimo as conversões de/para a forma OO).

Strings

Menção honrosa vai para o tipo String da JavaFX Script, que ao contrário de Java, é definido como um value type. Além disso, carrega um lote de funcionalidades extra:

·      O valor default de uma String não inicializada é "" (string vazia). É impossível ter uma string null; se você fizer esta atribuição, fica com "". Nunca acontecerá uma NullPointerException envolvendo strings (ou qualquer value type);

·      O operador == equivale a equals(), não há distinção entre igualdade e identidade (novamente, como todos value types);

·      Pode-se mesclar strings com expressões, por exemplo: "Alô, {nome}!" será expandido conforme o valor dinâmico da variável nome. Ou então, "Temperatura: {%2.2f temp}", a variável temp será formatada no estilo de System.printf() (ex.: %2.2f 32.257 ? 32,25);

·      Pode ser delimitada por aspas simples ou duplas, ex.: 'String com "aspas duplas" dentro';

·      Internacionalização é simples: def msg = ##"ERRO" irá atribuir a msg o valor da string associada à chave ERRO no resource bundle da aplicação; se não existir este resource, o valor da string será "ERRO" mesmo. Para separar a chave do valor default, use ##[ERRO]"Deu zebra!";

·      É o único tipo de JavaFX Script para manipular caracteres. Não existe um tipo específico para um caractere único, como o char do Java. Conversões automáticas são feitas ao invocar classes/APIs de Java que utilizam char; ex.: "Osvaldo".charAt(0) = "O".

 

Duration

O tipo de valor Duration representa uma quantidade de tempo. Exemplos de literais: 15ms (15 milissegundos), 2.3s (2.3 segundos), 55m (55 minutos), 10h (10 horas), 10h + 5m (10 horas e 5 minutos). Este tipo não passa de um açúcar sintático para um long contendo o tempo normalizado para milissegundos, mas ao usar o framework de animação da JavaFX, você verá que é muito conveniente ter uma sintaxe especial para isso.

Void

O Void do Java FX significa o mesmo que o do Java, mas é mais útil, ver seção Controle.

Referência

Os reference types da JavaFX também são familiares. Ver seções sobre funções e sequences.

Funções

JavaFX Script possui funções de primeira ordem. Exemplo:

 

var validador: function (o:Object): Boolean

 

O tipo da variável validador é uma função que possui um parâmetro do tipo Object e retorna um Boolean. Portanto, funções podem ser atribuídas a variáveis, passadas como parâmetro, etc. como quaisquer outros tipos. A linguagem Java possui uma aproximação desta facilidade, combinando interfaces com inner classes – mas o resultado é uma sintaxe confusa. Com a versão muito melhorada de JavaFX, podemos escrever por exemplo um tratador de eventos assim:

 

Stage {

    onClose: function() { FX.exit() }

}

 

Funções suportam os seguintes modificadores (antes do function):

·      Visibilidade (public, protected, package, e por default script-private);

·      abstract, igual a Java;

·      override, igual ao @Override do Java 5 (mas é mandatório);

·      bound, que examinaremos em Binding;

·      Não há nada equivalente ao final dos métodos Java.

Sequences

As sequences da JavaFX Script possuem sintaxe similar, mas significado e capacidades diferentes dos arrays do Java. Em comum com os arrays, as sequences são coleções de objetos de um tipo homogêneo e com tamanho fixo, indexadas a partir da base 0.

 

SEQUENCES

"> ...

Editorial

A capa desta edição é dedicada ao servidor de aplicações JBoss, o que aconteceu pela última vez há dois anos (Edição 46). Nesse ínterim cobrimos vários softwares da “família JBoss” (Hibernate, Seam, ESB...), mas o JBoss AS andou longe dos holofotes, que em geral destacam novidades. Como o novo JBoss AS 5, finalmente liberado. Esta nova versão tem grande importância devido ao suporte certificado à plataforma Java EE 5 e também à renovação da arquitetura interna do servidor – como explica nosso artigo, numa cobertura aprofundada que faz jus ao release.

Continuamos também acompanhando o lado Spring da força, dessa vez com foco no Spring Security, que oferece facilidades de controle de acesso e autenticação poderosas e simples de integrar à sua aplicação.

A palavra “integração”, por sinal, provavelmente pode ser encontrada em qualquer edição da Java Magazine. O site eaipatterns.com e o livro que o acompanha são a mais importante linguagem de design patterns disponível para o desenvolv"> ...

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

Clique aqui para ler esse artigo em PDF.

Mini-curso

Programação Java ME

Parte 4: Portabilidade e Desempenho

Analisando implementações de Java ME, otimizando código ao máximo e trabalhando para aumentar a portabilidade e reduzir os efeitos da fragmentação

O leitor que está seguindo este mini-curso verá que nesta edição tivemos que reduzir o ritmo temporariamente, fazendo um artigo mais curto que os anteriores. O motivo é o lançamento próximo do novo Eclipse, evento que sempre pede cobertura num momento oportuno para leitores interessados neste IDE. Teremos pelo menos mais um artigo completo de Java ME neste mini-curso, onde falaremos de outras APIs fundamentais da MIDP, como a RMS e a WMA. (Posteriormente, teremos outros artigos eventuais sobre a plataforma Java ME nesta coluna.)

Todavia, para não deixar o leitor aficionado em Java ME a ver navios, apresentamos nesta edição material concentrado em dois aspectos importantes na criação de aplicações Java ME. O texto não tem dependências fortes com o artigo anterior. O projeto Java ME mencionado em alguns pontos é um gerador de fractais chamado Micromandel, cujos fontes e binários estão disponível no download da edição anterior (e também desta).

A portabilidade das JVMs ME

Como temos visto nas partes anteriores, as JVMs para dispositivos limitados são também limitadas: seus compiladores JIT, Garbage Collectors e outros componentes são menos avançados que os de JVMs Java SE, pois devem “caber” nos dispositivos. Estas limitações têm uma conseqüência. APIs, frameworks, aplicações etc. que abusam de design orientado a objetos moderno (abstração, polimorfismo, encapsulamento) e oferecem muita funcionalidade, dependem muito de JVMs eficientes. E a falta de determinadas otimizações é ainda mais grave, se lembrarmos que o hardware destes dispositivos é dezenas de vezes inferior ao de PCs.

Código nativo?

Uma solução possível seria explorar mais a opção por código nativo, para implementar com desempenho máximo pelo menos as APIs mais críticas. Isso talvez reduzisse a necessidade de simplificar ou substituir algumas APIs. Parece boa idéia, lembrando que as interfaces nativas proprietárias das JVMs para Java ME são mais eficientes que a nossa conhecida JNI. (Na Java ME, cada JVM define a interface nativa que quiser, que pode ser otimizada para a plataforma. Estas interfaces proprietárias só podem ser usadas pelo runtime Java, jamais por código de aplicações.)

O problema é que o mercado de dispositivos Java ME – basicamente, telefones celulares e PDAs – é ainda muito fragmentado. Quem acha ruim portar código C/C++ entre Windows, Mac OS X e variantes de Linux/Unix, não conhece o caos (tanto na variedade quanto na qualidade) dos sistemas operacionais e SDKs para celulares. Pior ainda, estas plataformas mudam muito rápido, algo típico do mercado de “eletrônica de consumo”. E há um agravante: as JVMs para Java ME precisam ser muito customizáveis, adaptáveis e extensíveis, para se adaptarem não só a diferentes CPUs e sistemas operacionais, mas às decisões específicas a cada fornecedor e a cada produto.

A conclusão é que, longe de poderem ser mais otimizadas para cada plataforma de hardware e sistema operacional, as JVMs ME precisam ser ainda mais portáveis que as JVMs SE! Isso é verdade, por exemplo, para a KVM + CLDC HotSpot da Sun (que é licenciada para muitos fornecedores de dispositivos – e cujo código-fonte já foi totalmente liberado sob licença GPL; por isso podemos examinar). De fato, os fontes da KVM possuem proporcionalmente menos código Assembly, menos código C/C++, e menos código específico para CPUs e sistemas operacionais particulares, do que os fontes do Sun JDK para Java SE. Isso é conseguido com opções de design muito diferentes das que são comuns em JVMs SE.

Design para portabilidade

Por exemplo, a KVM implementa threads por conta própria, sem qualquer ajuda do sistema operacional (portanto, o código que faz isso é 100% portável). As desvantagens? Praticamente nenhuma, pois (1) o suporte a threads nativos dos sistemas operacionais para dispositivos como celulares varia entre “não suportado” e “péssimo”[1]; e (2) estas plataformas nunca têm múltiplas CPUs (multi-core ou SMP), o que seria o maior motivo para se preferir threads nativos.

Pelo contrário, como a JVM é capaz de controlar e modificar facilmente todo o código executável, ela pode inserir no código (interpretado ou compilado) “pontos de yield” em locais estratégicos, dando uma chance à JVM de alternar entre vários threads. Em comparação, nas aplicações nativas estes pontos precisam ser determinados pelo programador, e um trabalho imperfeito pode resultar em problemas que vão desde desperdício de CPU e pequenas “travadas”, até problemas mais sérios como livelocks.

Otimizando o bytecode

Quando se trata de economizar bytes, na Java ME nenhuma economia é demais. Ainda mais considerando que muitos dispositivos MIDP se recusam a instalar JARs com mais de 300 Kb. Este é o tamanho máximo cujo suporte é obrigatório pela especificação Mobile Service Architecture (veja a edição anterior).

A compressão dos arquivos JAR ajuda um pouco, pois a especificação fala no tamanho do JAR e não no tamanho normal das classes descompactadas. Ainda assim, para uma aplicação de tamanho realista, 300 Kb não é uma folga muito grande, ainda mais considerando que este limite inclui todos os recursos que possamos querer incluir no JAR, como ícones, imagens e áudio.

Para avaliação, a primeira versão do projeto da edição anterior, com somente código de navegação entre dois forms vazios, gera um JAR de 1.737 bytes (já com compressão ZIP). Não é tão pouco – 0,5% do limite de 300 Kb – para um programa que ainda não faz praticamente nada!

Leitores mais experientes em Java SE lembrarão do compressor Pack200, que permite reduzir arquivos JAR mais ainda do que qualquer outro compressor de uso geral, e é muito utilizado para gerar instaladores ou em aplicações Web Start. O problema é que o Pack200 é pesado para os padrões dos dispositivos ME, e só é adequado à distribuição por rede. Quando você instala o Sun JDK ou JRE, que é um procedimento bem demorado considerando o tamanho do instalador, a maior parte do tempo é gasta pela descompressão Pack200. Mas graças a isso só precisamos fazer um download de 57 Mb para instalar um software de 162 Mb (usando o JDK 6.0u1 como exemplo). Porém, o Pack200 só se justifica pela economia de tempo de transmissão por rede. Na instalação, as classes precisam ser convertidas para o formato normal (arquivos JAR comuns utilizando somente compressão ZIP). Se fossem mantidas em formato .pack, seu carregamento pela JVM seria lento demais. Isso porque este formato é “denso”; não permite ler uma classe arbitrária no meio do arquivo sem antes descomprimir todo o arquivo até aquela posição.

Para reduzir o bytecode ainda mais, utilizamos ofuscadores de bytecode. Estas ferramentas (como sugere seu nome) foram originalmente criadas para proteção de propriedade intelectual. Elas distorcem o bytecode, por exemplo substituindo nomes de atributos e métodos por nomes sem significado. Isso torna muito mais difícil o trabalho de algum xereta com um descompilador, que queira fazer a engenharia reversa dos fontes (pois os .class normais são fáceis de ler e de transformar automaticamente em código-fonte razoavelmente próximo ao original).

Nota 1: Tanto o Symbian quanto o BREW só oferecem threads (e multitarefa) “cooperativa”,  uma tecnologia dos tempos do Windows 3.1. O Windows CE é melhor, implementando scheduling preemptivo, mas o CE só é capaz de rodar numa variedade de equipamentos muito mais estreita (com requisitos mínimos bem maiores que os celulares médios atuais). Também há alguns fornecedores começando a utilizar o Linux, mas isso é incipiente e ainda não se pode dizer que o Linux esteja bem adaptado para plataformas como celulares.

"> ...

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

Clique aqui para ler esse artigo em PDF.

Mini-curso

Programação Java ME

Parte 2: Ferramentas e Primeiros Passos

Comece a programar para a plataforma Java ME, com o Wireless Toolkit e o Eclipse, MTJ e EclipseME

Este artigo continua a série iniciada na edição anterior, na qual introduzimos toda a complexa variedade de configurações, perfis e APIs que fazem parte da plataforma Java, Micro Edition. (Note que este artigo é bastante independente do anterior, podendo ser acompanhado inteiramente tendo-se apenas conhecimento inicial sobre Java ME.)

Como anunciado, daqui em diante iremos nos concentrar na configuração CLDC e no perfil MIDP, por serem os mais populares – e de aplicabilidade mais provável – devido à enorme disponibilidade dos dispositivos que implementam este perfil, os telefones celulares.

Aliás, se você tem um celular razoavelmente recente, este é um aparelho tão poderoso que usá-lo para fazer ligações de voz parece um desperdício! Algo como usar uma Ferrari para ir comprar pão na esquina. Vamos, então, pôr as mãos à obra e dar um bom uso à surpreendente capacidade de processamento que carregamos no bolso.

 

Ferramentas para MIDP

O programador Java moderno está habituado a ferramentas de desenvolvimento de alto nível, e se precisamos delas para criar sofisticadas GUIs (interfaces gráficas) ou gigantescos servidores “Enterprise Edition”, não é porque o Java ME é “micro” que nos contentaremos com ferramentas rudimentares. Pelo contrário, existe hoje uma boa variedade de IDEs com bom suporte para esta variante do Java.

Conheceremos três destas ferramentas aqui: o Wireless Toolkit (WTK) da Sun, e os plug-ins para Eclipse MTJ e EclipseME. Vamos explorar as funcionalidades disponíveis nestes programas, a sua configuração, e usar um projetinho “alô mundo” para nos ambientarmos. No próximo artigo da série, cobriremos também o NetBeans Mobility Pack, e construiremos uma MIDlet completa (mas sem depender de nenhum IDE ou plug-in específico, somente do WTK).

 

Trabalhando com o Java Wireless Toolkit

O WTK é o “JDK do Java ME”, por dois motivos. Primeiro, contém ferramentas essenciais para desenvolvimento para Java ME, como o pré-verificador (bin/preverify), o emulador de dispositivos CLDC (bin/emulator), e as bibliotecas necessárias para compilar e testar seus programas. Segundo, ferramentas mais avançadas, como plug-ins de IDEs, costumam depender do WTK. Se você instalar algum IDE ou mesmo um plug-in Java ME que não exige uma instalação prévia do WTK, tipicamente é porque o WTK já vem embutido.

O WTK pode ser baixado de java.sun.com/products/sjwtoolkit. Neste artigo apresentamos o WTK 2.5, cujo release final foi recentemente disponibilizado. Este release necessita do Java SE 5.0 ou superior. Se você já usou versões anteriores do WTK, veja o quadro “As novidades do WTK 2.5”.

 

Figura 1. Tela principal do WTK.

Após a instalação, execute o Wireless Toolkit (ktoolbar). Ao contrário do JDK, que só oferece ferramentas de linha de comando, o WTK inclui muitas ferramentas gráficas. A Figura 1 mostra a principal delas, o emulator, em ação, logo após compilar e executar um projeto. Para fazer esta execução de teste, selecione Open Project, abra um projeto (é apresentada uma lista com todos os demos incluídos no WTK), e execute-o com Run. Você verá um emulador de celular, como mostrado na Figura 2. As teclas do aparelho emulado podem ser acionadas pelo teclado ou clicando sobre as mesmas com o mouse. Após a execução, serão exibidas algumas estatísticas de desempenho.

 

Figura 2. Emulador de celular, exibindo o demo JBricks.

Finalmente, o botão Settings permite visualizar e modificar a configuração de um projeto. A Figura 3 mostra uma das páginas do extenso diálogo de configuração. Este diálogo configura tanto as opções de compilação (que ficam num project.properties no diretório-raiz do projeto) quanto os descritores de deployment (MANIFEST.MF) que as MIDlets exigem.

 

Figura 3. Propriedades de um projeto do WTK.

 Não investiremos tempo criando programas com o WTK, que não é, sozinho, um IDE completo. Mas apresentaremos uma visão geral das suas ferramentas. A Tabela 1 lista todos os programas encontrados no seu diretório bin, cujo conhecimento é útil mesmo que na maior parte do tempo você use IDEs. Os IDEs, em grande parte, irão automatizar o uso destas ferramentas, portanto os conceitos e capacidades são um aprendizado reusável.

Ferramenta

Descrição

"> ...

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

 

 

Atenção: por essa edição ser muito antiga não há arquivo PDF para download.Os artigos dessa edição estão disponíveis somente através do formato HTML. 

 

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 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[2], 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.

É importante observar que os releases do projeto Blackdown não são livres: eles não incluem código fonte nem têm uma licença livre. Por outro lado, para quem optar por variantes do Linux não suportadas pela Sun e por outras empresas, o Blackdown é a única opção compatível e de alto desempenho. Por isso, o projeto serve aos interesses dos usuários do Linux, ainda que com restrições.

A Sun passou a suportar o Linux a partir do J2SE 1.3.x, e atualmente este suporte é excelente. Os releases para Linux são simultâneos com as versões Solaris e Windows, sendo todos compilados de uma árvore única de código-fonte. E o desempenho é igual em todas as plataformas, descontando itens que dependem do suporte da plataforma. (Por exemplo, até há pouco – antes da NPTL[3] – a escalabilidade de threads no Linux era sofrível, mas isso era culpa do Linux e não do Java.)

O suporte ao Linux por parte da Sun não significou o fim do projeto Blackdown, pois a Sun não suporta toda a variedade de distribuições e plataformas de hardware suportado pelo Linux. O J2SE da Sun suporta oficialmente apenas o Red Hat (embora funcione bem em outras distribuições) e é distribuído apenas para as plataformas PC (x86, Itanium e AMD64). O mesmo vale para as JVMs da IBM e da BEA. Já os builds do Blackdown tendem a suportar melhor outras distribuições, e também outras CPUs como PowerPC e SPARC. Isso não deve mudar tão cedo, pois o Linux/SPARC dificilmente seria suportado pela Sun, por ser um competidor direto do Solaris; e o Linux/PowerPC idem para a IBM, pois compete com o AIX. Faz sentido para estas empresas suportar o Linux em hardware de outras empresas (Intel e AMD, “exorcizando” o Windows), mas não no próprio hardware, o qual faz parte de soluções mais abrangentes.

Para os usuários de Linux, o projeto Blackdown continua importante, embora esteja sempre um passo atrás das versões da Sun (o porte do J2SE 5.0, em andamento, ainda está indisponível). Por outro lado, as melhorias feitas pelo grupo Blackdown também são contribuídas para a Sun, e eventualmente aparecem nos releases oficiais do Sun JDK.

Escolhendo o seu J2SE

O J2SE pode ser modificado em diferentes graus e lugares, conforme os interesses e especialidades de cada empresa. Pode-se mexer na JVM, ou nas APIs, ou em ambos. Das alternativas mostradas, o JDK da IBM é a que mais desvia da implementação de referência da Sun, pois substitui totalmente a JVM e reimplementa várias APIs.

Estas modificações não podem violar o JCK (a coleção de testes de compatibilidade do J2SE), mas às vezes ocorrem diferenças que não são cobertas pelo JCK e podem surpreender. Por exemplo, as APIs de segurança do IBM JDK suportam um conjunto de algoritmos de criptografia, hashing, assinaturas digitais etc. bem maior que as do JDK da Sun. A especificação do J2SE define provedores de segurança plugáveis (através da API JCE), e cada JVM pode implementar os provedores que quiser. Mas um desenvolvedor poderia escrever código que exige um algoritmo suportado apenas pelo IBM JDK[4]. E o programa resultante não funcionaria na JVM da Sun, mesmo sendo 100% Java! Isso, no entanto, não é diferente de escrever um programa com JDBC que não é portável porque usa, por exemplo, comandos SQL com extensões do Oracle. Veja o quadro “Uma lição em compatibilidade do Java”.

De todas as JVMs analisadas neste artigo, os campeões de desempenho são as da Sun, IBM e BEA (os releases Blackdown têm desempenho semelhante aos da Sun). Há uma forte competição entre esses fornecedores, e as JVMs ajudam a vender outros produtos, como hardware ou servidores J2EE. Um fator de diferenciação importante entre as diversas JVMs costuma ser o nível de suporte dado a diferentes plataformas ou cenários de uso. Veja o quadro “Qual é o Java mais rápido?”.

Uma última observação importante sobre as JVMs modificadas por licenciados da Sun é que, segundo a licença entre a Sun e estas empresas, quaisquer melhorias em código criado inicialmente pela Sun devem ser repassadas de volta à Sun, que pode aproveitá-las nas suas versões futuras do JDK. A IBM e Apple fizeram muitas melhorias que depois foram incorporadas à implementação da Sun. Por outro lado, quando um licenciado reimplementa totalmente algum componente do J2SE (sem se basear no código da Sun), este compartilhamento não é obrigatório. Por exemplo, a Sun não tem direitos sobre o código do compilador JIT, implementações de garbage collectors e outros componentes da VM da IBM.

Java Livre

Para muitos, uma das principais motivações para implementações alternativas do Java é o desejo de se ter uma plataforma Java que seja totalmente livre/open source.

A Sun tem aberto a implementação do Java de forma gradual: primeiro com a licença SCSL, depois com a JRL (veja as conclusões desta seção: “O futuro do Java Livre”), e mais recentemente com os builds do Mustang disponíveis semanalmente no portal java.net. Mas ainda não saiu um release totalmente aberto, sob uma licença aprovada pela OSI (Open Source International) ou FSF (Free Software Foundation). Outras JVMs de código fechado como o IBM JDK e o JRockit da BEA, embora disponíveis para Linux, são ainda mais fechadas. Não há nenhum acesso público ao código fonte, nem mesmo com licenças restritivas.

Enquanto esta situação não muda, um número cada vez mais de voluntários dedica-se a criar implementações livres do Java.

 (~1.4) Classpath: gnu.org/software/classpath

As APIs constituem uma fatia enorme do J2SE e talvez sejam mais difíceis de implementar que a JVM em si. Uma implementação da JVM com alto desempenho e qualidade é um projeto gigantesco. Mas uma implementação que somente “dê pro gasto” é relativamente simples – tanto que há uma profusão de projetos de máquinas virtuais Java. Por outro lado, mesmo uma implementação básica das APIs é uma grande façanha. As APIs são muito numerosas, e até as aplicações mais simples necessitam (direta ou indiretamente) de muitas APIs. O resultado é que só existe um projeto relevante de implementação livre das APIs do J2SE: o GNU Classpath, da Free Software Foundation (FSF).

O Classpath tem por objetivo implementar todos os pacotes java.*, javax.* e org.* que constituem as APIs padrão do J2SE. Ao contrário dos projetos mostrados anteriormente, isso é feito pelo método “clean room”, sem utilizar – nem sequer olhar – uma única linha de código-fonte da Sun.

As bibliotecas do Classpath têm licença LGPL. Raramente alguém precisará instalar essas APIs. O mais comum é instalar alguma implementação livre de Java que incorpore o Classpath, como o Kaffe ou o GCJ.

O projeto Classpath mantém estatísticas de compatibilidade com diversas versões do J2SE (de 1.0 a 1.4). A Tabela 1 resume estas estatísticas (extraídas da seção Status do site do projeto).

 

Tabela 1. Estatísticas de compatibilidade do Classpath

Versão de Java

Compatibilidade

"> ...