Notícia publicada por brain em junho 11, 2004 10:49 AM
| TrackBack
O Eclipse é um ambiente de desenvolvimento bastante popular para programadores Java, C e C++. Ele próprio sendo desenvolvido em Java, até recentemente seus usuários tipicamente precisavam recorrer a programas de código-fonte fechado (para ser específico, a máquina virtuakl Java da Sun) para executá-lo. Mas segundo o Linux Journal, a Red Hat acaba de mudar este quadro. Procurando reduzir o tempo de inicialização, ganhar em desempenho e oferecer suporte a plataformas adicionais (especificamente a plataforma Intel de 64 bits, para a qual não havia JVM disponível no momento do desenvolvimento da solução), a Red Hat lançou uma versão do Eclipse independente de JVM, compilada com o GCJ (e a libgcj), que geram programas para execução nativa, da mesma forma que o GCC (e a libc) permitem para programas em C. Os detalhes técnicos são interessantes eestão disponíveis no link acima.
Ok, foi lançada uma versão sem JVM mas e os 'adicionais' que o Eclipse possui, ou seja, todos os plugins para outras linguagens, interfaces, JaveBeans, ANT, TomCAt, etc..
Serão mantidos, ou convertidos? A criação ou compilação de uma nova versão fora do padrão do eclipse.org pode gerar problemas, já que serão duas equipes distintas cuidando de um mesmo produto.
Podemos ter problemas ou particularidades distintas em cada IDE.
Isto é medo de desenvolvedor, mas no fundo é uma solução excelente, ficam as minha dúvidas.
AH, to loco pra testar... pq o eclipse GTK normal, no linux é extremamente lento.
Wagner, você teve esta dúvida após ler o artigo, ou sem ler?
Pergunto porque para mim a parte cujo título é 'Changes to Eclipse' não deixou muitas dúvidas de que as mudanças no Eclipse em si foram mínimas (inclusive, mesmo após alterado, ele ainda pode opcionalmente ser rodado usando a JVM se alguém quiser), e que ele mantém suas interfaces.
Mais adiante, no título 'Limitations', consta o que ele ainda não pode fazer na versão nativa. E não é muita coisa.
Abraços
Augusto
Bom, eu empacoto o eclipse pra Conectiva e sei o trabalhão que é.
Já fiz o que a RH fez aqui como teste, mas como temos licença de redistribuição da JVM/JDK da Sun, decidi manter a mesma.
Porém o ponto necessariamente é o ganho de performance, e não o "livre" como mencionado, devido ao fato que se tratando da linguagem Java estamos no mesmo terreno pantanoso de linguagens como C# ( Mono ).
Se em algum devido momento a Sun decidir fazer um reclame sobre a API usada no gcj, como a MS pode fazer sobre o Mono, estaremos a mercê deles.
Nós podemos mesmo dizer livre quando pudermos ver uma GPL ou similar travada sobre o código oficial da API.
Salvo engano, má compreeção do inglês ,ele fala em arquitetura AMDx86-64 e não intel-64.
Achei ótima essa idéia. Já que a Sun não se decide quanto à liberação do código de sua JVM, o que todos deveriam é melhorar o gcj para tornar o java mais adequado como linguagem de programação genérica. Sinceramente não acredito em bom desempenho de nenhuma linguagem interpretada (ou semi-interpretada), mesmo com os truques modernos (compilação JIT e etc).
Eu já usei o Eclipse e não achei tão lento assim para uma aplicação Java, muito pelo contrário. Claro que tenho bastante RAM aqui, mas os microprocessadores dos meus computadores não são de última geração.
Gostaria de alertar a todos que programam em Java para usar o kernel 2.6 que tem implementação nativa de java e o JVM da blackdown. http://www.blackdown.org...
Olha os ganhos de velocidades na virtual machine na SUN contra a da Blackdown. Feitos no kernel 2.4.x 3 2.6.x...
Tempo para iniciar o JBOSS nas mesmas condições em Pentium IV 2.66, 512MB:
-------------------------------------------------------
JBOSS Kernel 2.4.x
VM da SUN: 55s:872
VM da BLACKDOWN: 44s:829ms
-------------------------------------------------------
-------------------------------------------------------
JBOSS Kernel 2.6.5
VM da SUN: 44s:798ms
VM da BLACKDOWN: 40s:390ms
-------------------------------------------------------
Ganho no mínimo de 4 segundos chegando a 10s. No final do dia, com várias aplicações no servidor jboss isto pode fazer uma diferença muito boa.
Abraços
Fuji: o kernel 2.4 não tinha threads de verdade. Como Java faz uso intenso de threads, era aquela tristeza.
Hélio: sempre a mesma história de Java e GPL. A Sun nunca fechou nem cobrou RPC, Nis, NFS, e abriu o Open Office. Se ela fechar, por exemplo, a versão X, a comunidade pode pegar a versão anterior (que é padrão aberto) e continuar o desenvolvimento. Existem ainda as implementações livre, como Kafee e Blackdown.
Sempre trabalhei com Java, além de outras linguagens. Nunca tive problemas com licenças, e nunca paguei para desenvolver. E também não escuto reclamações neste sentido de quem desenvolve.
Sobre a notícia: é boa a idéia, já que o Eclipse é realmente pesadinho.
mas (fuji) Mike Shigueru Matsumoto como eu faço isso? é so substituir o jvm instalado da Sun pelo blackdown? ou tem q configuar mais alguma coisa no kernel? (uso suse 9.1)
Eu queria começar a desenvolver em Eclipse, mas não encontrei muito material na internet, alguem sabe onde conseguir um forum ou algum material
Esta iniciativa (eclipse compilado com gcj) já existia, conforme http://klomp.org/mark/gij_eclipse/. Não tenho certeza qual versão do eclipse foi utilizada.
Outro ponto incorreto no artigo é que afirma que não existe uma versão do swt para arquitetura AMD64, pois existe, já há algum tempo, a versão inteira do eclipse para esta arquitetura, incluindo a SWT.
[]s
Peter Parker,
o Blackdown não é nem um pouco livre.
Ele é baseado no código da JVM da Sun, e é protegido por contratos de não-divulgação do código-fonte.
Se você acha que ele é livre, poste um link para o código-fonte :)
Além da independência de software proprietário, o bom é a independencia de VM, já que se uma distribuição é otimizada para a rquitetura x, o software que a acompanha poderia ser todo *compilado* para essa arquitetura.
eu: vc tá certo. Só o kafee mesmo é implementação livre. Pena que não presta :(
Peter Parker : não fale bullshit, o kaffe é ótimo e MUITO rapido ... o unico problema é que ele implementa as especificações do java 1.1 com pouquissimas coisas do 1.2 ... ou seja: está bem atrazado em comparacao das versoes atuais.
Peter,
alem do kaffe, também existe o sablevm, que dizem ser bom...
http://www.sablevm.org/
E vale lembrar que a máquina virtual, em si, não é suficiente. Uma gigante biblioteca de classes também faz parte da definição de "Java", e essa biblioteca é implementada pela Gnu Classpath.
Hélio, a especificação do C# é aberta, não a implementação da linguagem e da VM da Microssoft, mas a especificação da linguagem e de algumas coisas da plataforma .NET.
Também não vou muito com a cara de linguagem interpretadas ou semi-interpretadas, mas é isso.
Aqui ta um links sobre o que falei.
http://msdn.microsoft.com/net/ecma/
Achei os links das especificações do C# e da Common Language Infrastructure (CLI), resumindo, o .NET é uma implementação da CLI, assim como o MONO.
ECMA-335 e ECMA-334
http://www.ecma-international.org/publications/standards/Ecma-335.htm
http://www.ecma-international.org/publications/standards/Ecma-334.htm
Juro que também fiquei espantado quando soube disso... hehe.
Nobody: quando eu disse "não presta", quis dizer que é padrão antigo. Me expressi mal.
Comentários desativados: Esta discussão é antiga e foi arquivada, não é mais possível enviar comentários adicionais.