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!
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
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.
[fechar]
Você não gostou da qualidade deste conteúdo?
(opcional) Você gostaria de comentar o que não lhe agradou?
Java Magazine 78
[Artigo disponível no Leitor Digital DevMedia. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da Java Magazine 78
[Artigo 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;
"
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;
"
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!
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
Osvaldo Pinali Doederlein
é 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.
O que você achou deste post?
Cursos relacionados
Publicidade
