Pular para o conteúdo

GCJ – Conhecendo o compilador Java Livre

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.
Alessandro de Oliveira Faria (A.K.A. CABELO) CABELO
Hits: 30.956 Categoria: Java Subcategoria: Avançado
  • Indicar
  • Impressora
  • Denunciar

Introdução e instalação:


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.

   1. Introdução e instalação:
   2. Compilando e testando um programa exemplo
   3. Gerando um bytecode com o programa "OLA MUNDO"
   4. Testando a performance (compactando um vídeo mpeg)

NagiosVision: Tem humanos perto do seu servidor

Android NDK: Desmistificando o acesso a códigos nativos em C

Criando aplicativos para o Mac OS X no GNU/Linux

Artigo número 100: AR.Drone - O robô voador com Linux embarcado

GAMBAS: A definitiva resposta open-source ao Microsoft Visual Basic

PDFBox - Aplicativo Java para baixar o DOU completo

Trabalhando com classes e métodos em Java

Linux + Rails + Ruby + Mongrel + PostgreSQL + NetBeans 6 Preview

Preparando ambiente de desenvolvimento Android no Debian/Ubuntu

Configurando e-Gen + Tomcat + JSDK

#1 Comentá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.
#2 Comentá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.

#3 Comentário enviado por leibniz em 05/07/2006 - 15:19h
A função "import javax.swing.JOptionPane;" funciona no gcj.
#4 Comentário enviado por drausio em 05/07/2006 - 17:31h
Ae Cabelo!!!!

Cara muito xique heim!
Parabéns mais uma vez... =)
#5 Comentá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....

Para conferir:
http://www.oesf.org/forums/index.php?showtopic=18988&hl=java
#6 Comentá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
#7 Comentá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.
#8 Comentá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...
#9 Comentá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.
#10 Comentário enviado por removido em 14/02/2008 - 11:15h
Bom artigo eu gostei apesar de nunca ter testado o Gcj...
#11 Comentá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.

Contribuir com comentário

Entre na sua conta para comentar.