Com a repercussão gerada quando a Sun resolveu disponibilizar o código fonte do Java, resolvi testar o Java Livre. O projeto GCJ da GNU é um compilador Java totalmente livre, onde o desenvolvedor pode gerar bytecode ou código binário nativo. Não sou especialista em Java, mas fiquei surpreso ao executar os testes mencionados neste documento.
O projeto GCJ é um compilador Java 100% livre no qual podemos gerar bytecodes ou binários nativos. Baseado em algumas pesquisas, cheguei a conclusão que existe suporte ao kit Java J2SE 1.4.2, mas não na API Swing. Mas acredito que esta não disponibilidade é apenas uma questão de tempo.
A Red Hat há algum tempo lançou uma versão do Eclipse que não depende da JVM, compilada com o GCJ, gera programas para execução nativa, como o compilador GCC. O Eclipse é um ambiente de desenvolvimento utilizado por programadores Java, C e C++.
Em aproximadamente em fevereiro de 2006, foi disponibilizada à comunidade a versão 4.1.0 do GCC com diversas mudanças.
O GCC possui front-ends para as linguagens C, C++, Objective C, Fortran, Java e Ada e suas respectivas bibliotecas. Sendo assim posso dizer que estamos mais próximo de um compilador livre para Java com capacidade de traduzir bytecodes ou código-fonte em Java para código executável nativo. Imagine a portabilidade do Java junto a performance do compilador C.
Instalação dos pacotes necessários:
Em minha distribuição SuSE bastou utilizar os pacotes gcc-java, libgcj e libgcj-devel, como no exemplo abaixo:
Para efeito de informação, a libgcj fornece para a aplicação os componentes em tempo de execução que seriam fornecidos pela JVM.
#1Comentário enviado por removido em 05/07/2006 - 11:10h
Legal.
Eu sabia da existência do GCJ, mas não sabia q ele gerava código nativo, e tbém nunca havia utilizado ele por causa de suas restrições. Atualmente estou desenvolvendo um software relativamente grande em Java, e estava preocupado com a performance, eu tava mesmo querendo gerar código nativo. O problema é que ele está 100% em J2SE 5.0, e com o GCJ não tenho como utilizar todos os recursos. Seria legal se os desenvolvedores conseguissem manter o GCJ sempre com as mesmas características da JVM da Sun.
#2Comentário enviado por jragomes em 05/07/2006 - 11:44h
Cabelo,
Parabéns, mais uma vez trazendo um artigo bom, bem explicativo e trazendo coisas novas.
#3Comentário enviado por leibniz em 05/07/2006 - 15:19h
A função "import javax.swing.JOptionPane;" funciona no gcj.
#4Comentário enviado por drausio em 05/07/2006 - 17:31h
Ae Cabelo!!!!
Cara muito xique heim!
Parabéns mais uma vez... =)
#5Comentário enviado por anunakin em 06/07/2006 - 20:18h
Fale cabelo,
Inclusive conseguimos usando o GCJ fazer os plugins JAVA (JavaApplets) funcionarem no Firefox do Zaurus, um PDA com Linux e processador ARM PXA270.. Coisa alias que a SUN fez foi desprezar totalmente os PDAs e por o J2ME como default... putz 640Mhz, Firefox, KDE, C++ e usar J2ME é cruel....
#6Comentário enviado por sombriks em 07/07/2006 - 03:28h
Massa Cabelo!
eu estou aprendendo java e realmente é legal saber que já possuo alguma possibilidade de produzir código nativo. O chato é a coisa do J2SE 5, como o tiagozc já falou. espero que a turma aí do GCJ nos dê mais alegrias, :D
#7Comentário enviado por EmanuelSan em 07/07/2006 - 09:23h
Fiz os testes na minha máquina com FC5 usando o programa Zipando.java disponibilizado pelo CABELO e consegui os seguintes resultados:
IBM Java 1.5.0 12.573s
GCJ 4.1.1-1.fc5 12.901s
GIJ 4.1.1-1.fc5 13.228s
SUN Java 1.5.0.07 19.173s
Meu arquivo tst.mpg tinha 100M. Refiz cada teste várias vezes e peguei o melhor resultado de cada. Olha que surpresa! O JIT que vem no JDK da IBM parece muito bom.
#8Comentário enviado por anunakin em 07/07/2006 - 09:52h
Esse JRE da IBM e o GCJ são os únicos que estão funcionando bem no meu AMD64 ... o da sun é só bugs e paw toda hora .. trava o firefox, uma tristeza...
#9Comentário enviado por cwars em 11/09/2007 - 18:47h
Eu havia lido um artigo de o porquê do GCJ e gij terem maiores performances que javac e java normal, mas os motivos são simplesmente que no GCJ e gij eles tiraram muitos dos overheads que exitem no java (como leitura e verificação de código para depois executar, linkagem dinâmica, sistemas de analize e segurança e entre outros), gerando uma forma que possa ser executada mais rapidamente, contudo mesmo o código compilado em código nativa continua sendo gerenciado e dependendo so gij para rodar, coisa que não poderam corrigir devido ao coletor de lixo.
#10Comentário enviado por removido em 14/02/2008 - 11:15h
Bom artigo eu gostei apesar de nunca ter testado o Gcj...
#11Comentário enviado por removido em 16/08/2009 - 02:13h
@CABELO
O quê está acontecendo com seus links?
Por que eles não seguem?
Eu estou procurando um compilador para Java e não estou muito afim de usar Windows, mas lendo seu artigo vi que os links estão falhando.
Preferências de cookies
Usamos cookies essenciais para manter o site funcionando. Cookies de estatísticas e anúncios só serão carregados se você permitir.
Eu sabia da existência do GCJ, mas não sabia q ele gerava código nativo, e tbém nunca havia utilizado ele por causa de suas restrições. Atualmente estou desenvolvendo um software relativamente grande em Java, e estava preocupado com a performance, eu tava mesmo querendo gerar código nativo. O problema é que ele está 100% em J2SE 5.0, e com o GCJ não tenho como utilizar todos os recursos. Seria legal se os desenvolvedores conseguissem manter o GCJ sempre com as mesmas características da JVM da Sun.