Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da Java Magazine DIGITAL ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
dê seu feedback
post favorito
Artigo Java Magazine 78 - Java à Moda do Freguês
Exploramos várias alternativas às JVMs comuns, como o Sun JDK ou IBM JDK, como plataforma de execução de aplicações Java. Estas alternativas incluem compiladores estáticos, implementações livres de Java, e até mesmo a execução de código java em VMs .NET.
Java Magazine 78
[Artigo já está disponível no Leitor Digital DevMedia®. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da Java Magazine 78
[Artigo já está disponível no Leitor Digital DevMedia®. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da Java Magazine 78
Java à Moda do Freguês
Explorando ambientes de execução alternativos
Veja como compilar estaticamente uma aplicação Java, gerando um executável nativo comum; rodar seu código Java na plataforma .NET; entre outras opções... entenda também o consumo de recursos dos programas Java
Este artigo explora opções alternativas de compilação e distribuição/instalação de aplicações Java. Todo desenvolvedor Java está acostumado com a opção “oficial” – compilar para bytecode com o javac, gerar arquivos como JAR/WAR/EAR, fazer deployment em containers Java EE ou talvez com JNLP para Applets e WebStart. Mas existem opções – já pensou em gerar um arquivo executável (como um .EXE no Windows) contendo uma aplicação Java completa, que não exige um JRE? Ou então, compilar uma aplicação Java de tal forma a executar na plataforma .NET? Neste artigo vamos explorar estas possibilidades, inclusive variações da opção mais tradicional, como o OpenJDK.
O leitor veterano desta coluna poderá lembrar do artigo “JVMs Alternativas”, Edição 24. Mas além da atualização dos últimos anos, a abordagem aqui é bastante diferente, e cobre em maior profundidade os poucos itens em comum.
Motivação e Histórico
Quando a plataforma Java foi lançada, se notabilizava por uma característica então bem pouco comum: o uso de uma Máquina Virtual (VM), arquitetura de execução que trazia vantagens como a distribuição de código em formato portável (bytecode) e com garantias de segurança e estabilidade (o que é atualmente chamado de “código gerenciado”). Existiam linguagens bem mais antigas que usavam VMs, mas Java inovou em alguns aspectos (especialmente no foco em código seguro) e teve o mérito de realmente popularizar o conceito de VM.
Muito do sucesso do Java deve-se à opção pela VM. Ainda assim, desde o começo, uma das perguntas mais comuns de iniciantes era: Dá para gerar um “programa compilado”? E não adianta apontar para o compilador JIT da JVM; para alguns, a necessidade de gerar um arquivo executável nativo, como um .EXE, continua sendo importante por outras razões – que podemos listar:
• Facilidade de distribuição/instalação de aplicações;
• Maior grau de controle/administração das aplicações instaladas;
• Vantagens de desempenho.
Algumas destas vantagens eram grandes nos primórdios da plataforma Java, o que abriu as portas para um competitivo mercado de “compiladores estáticos” para Java (neste artigo vamos chamá-los apenas de compiladores, para simplificar). Eu cheguei a testar e avaliar a maioria deles (ver quadro “Histórico: A primeira geração de Compiladores Java”).
Histórico: A primeira geração de Compiladores Java
Os leitores veteranos desta coluna terão flashbacks ao ouvirem nomes como TowerJ, BulletTrain, JOVE, Supercede, GCJ e JET; os mais iniciantes, porém, nem saberão do que se trata. Isso por que quase toda a primeira geração de produtos desse tipo – compiladores estáticos para Java – acabou não sobrevivendo. Isso aconteceu em parte por que a linguagem Java e seus frameworks foram projetados para serem executados por uma VM; o modelo de compilação estática, que serve muito bem a linguagens como C e C++, nem sempre é tão bom para Java. Mas é interessante examinar os motivos pelo quais estes produtos surgiram, e os motivos pelos quais a maioria não sobreviveu.
• Preço: Quase todos eram produtos comerciais, em geral bastante caros. Alguns tinham preços na ordem das dezenas de milhares de dólares; outros tinham um modelo de vendas bem estranho (você não podia comprar o compilador – precisava submeter seu bytecode à empresa, que devolvia o executável compilado);
• Visão de curto prazo: Os produtos exploravam fraquezas das primeiras versões do JDK. Por exemplo, o TowerJ devia muito do seu sucesso às suas bibliotecas otimizadas para I/O e threads, escalando para um número maior de conexões. O BulletTrain era bem melhor em GC e nas bibliotecas numéricas/matemáticas. O JOVE era melhor na otimização de código OO. Tão logo as JVMs (em especial a partir do JDK 1.2) recuperaram o atraso, oferecendo desempenho similar ou até melhor, e ainda por cima de graça, aqueles produtos deixaram de ser necessários;
• A bolha: O plano de negócio das empresas que investiram nestes produtos fazia mais sentido nos anos dourados do “dot-com”. Quando a bolha estourou e ninguém mais tinha dinheiro para produtos caros com vantagens modestas, a festa terminou. (Alguns dos desenvolvedores destes produtos acabaram arranjando emprego na Sun...);
• A revolução do HotSpot: Estes planos também se fiavam que a arquitetura de VM com compilador JIT nunca teria excelente desempenho. Era o que todo mundo pensava, pois era a realidade antes do Java2 e do HotSpot (e também do IBM JDK, que no mesmo período também estreou a VM “J9”). Quem apostava na tecnologia de compilação tradicional, a la C/C++, não enxergou a locomotiva dos compiladores JIT modernos, com otimizações dinâmicas e especulativas, surgindo no fim do túnel;
"
ATENÇÃO! A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVP
Explorando ambientes de execução alternativos
Veja como compilar estaticamente uma aplicação Java, gerando um executável nativo comum; rodar seu código Java na plataforma .NET; entre outras opções... entenda também o consumo de recursos dos programas Java
Este artigo explora opções alternativas de compilação e distribuição/instalação de aplicações Java. Todo desenvolvedor Java está acostumado com a opção “oficial” – compilar para bytecode com o javac, gerar arquivos como JAR/WAR/EAR, fazer deployment em containers Java EE ou talvez com JNLP para Applets e WebStart. Mas existem opções – já pensou em gerar um arquivo executável (como um .EXE no Windows) contendo uma aplicação Java completa, que não exige um JRE? Ou então, compilar uma aplicação Java de tal forma a executar na plataforma .NET? Neste artigo vamos explorar estas possibilidades, inclusive variações da opção mais tradicional, como o OpenJDK.
O leitor veterano desta coluna poderá lembrar do artigo “JVMs Alternativas”, Edição 24. Mas além da atualização dos últimos anos, a abordagem aqui é bastante diferente, e cobre em maior profundidade os poucos itens em comum.
Motivação e Histórico
Quando a plataforma Java foi lançada, se notabilizava por uma característica então bem pouco comum: o uso de uma Máquina Virtual (VM), arquitetura de execução que trazia vantagens como a distribuição de código em formato portável (bytecode) e com garantias de segurança e estabilidade (o que é atualmente chamado de “código gerenciado”). Existiam linguagens bem mais antigas que usavam VMs, mas Java inovou em alguns aspectos (especialmente no foco em código seguro) e teve o mérito de realmente popularizar o conceito de VM.
Muito do sucesso do Java deve-se à opção pela VM. Ainda assim, desde o começo, uma das perguntas mais comuns de iniciantes era: Dá para gerar um “programa compilado”? E não adianta apontar para o compilador JIT da JVM; para alguns, a necessidade de gerar um arquivo executável nativo, como um .EXE, continua sendo importante por outras razões – que podemos listar:
• Facilidade de distribuição/instalação de aplicações;
• Maior grau de controle/administração das aplicações instaladas;
• Vantagens de desempenho.
Algumas destas vantagens eram grandes nos primórdios da plataforma Java, o que abriu as portas para um competitivo mercado de “compiladores estáticos” para Java (neste artigo vamos chamá-los apenas de compiladores, para simplificar). Eu cheguei a testar e avaliar a maioria deles (ver quadro “Histórico: A primeira geração de Compiladores Java”).
Histórico: A primeira geração de Compiladores Java
Os leitores veteranos desta coluna terão flashbacks ao ouvirem nomes como TowerJ, BulletTrain, JOVE, Supercede, GCJ e JET; os mais iniciantes, porém, nem saberão do que se trata. Isso por que quase toda a primeira geração de produtos desse tipo – compiladores estáticos para Java – acabou não sobrevivendo. Isso aconteceu em parte por que a linguagem Java e seus frameworks foram projetados para serem executados por uma VM; o modelo de compilação estática, que serve muito bem a linguagens como C e C++, nem sempre é tão bom para Java. Mas é interessante examinar os motivos pelo quais estes produtos surgiram, e os motivos pelos quais a maioria não sobreviveu.
• Preço: Quase todos eram produtos comerciais, em geral bastante caros. Alguns tinham preços na ordem das dezenas de milhares de dólares; outros tinham um modelo de vendas bem estranho (você não podia comprar o compilador – precisava submeter seu bytecode à empresa, que devolvia o executável compilado);
• Visão de curto prazo: Os produtos exploravam fraquezas das primeiras versões do JDK. Por exemplo, o TowerJ devia muito do seu sucesso às suas bibliotecas otimizadas para I/O e threads, escalando para um número maior de conexões. O BulletTrain era bem melhor em GC e nas bibliotecas numéricas/matemáticas. O JOVE era melhor na otimização de código OO. Tão logo as JVMs (em especial a partir do JDK 1.2) recuperaram o atraso, oferecendo desempenho similar ou até melhor, e ainda por cima de graça, aqueles produtos deixaram de ser necessários;
• A bolha: O plano de negócio das empresas que investiram nestes produtos fazia mais sentido nos anos dourados do “dot-com”. Quando a bolha estourou e ninguém mais tinha dinheiro para produtos caros com vantagens modestas, a festa terminou. (Alguns dos desenvolvedores destes produtos acabaram arranjando emprego na Sun...);
• A revolução do HotSpot: Estes planos também se fiavam que a arquitetura de VM com compilador JIT nunca teria excelente desempenho. Era o que todo mundo pensava, pois era a realidade antes do Java2 e do HotSpot (e também do IBM JDK, que no mesmo período também estreou a VM “J9”). Quem apostava na tecnologia de compilação tradicional, a la C/C++, não enxergou a locomotiva dos compiladores JIT modernos, com otimizações dinâmicas e especulativas, surgindo no fim do túnel;
"
ATENÇÃO! A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da Java Magazine DIGITAL ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
Você está em:
canal Java
Publicidade
Osvaldo Pinali Doederlein
Space do autor
é Mestre em Engenharia de Software Orientado a Objetos e Arquiteto de Tecnologia da Visionnaire Informática, trabalhando em projetos de software e prospecção tecnológica.
Space do autor
0
0
