Visite também: UnderLinux ·  VivaOLinux ·  LinuxSecurity ·  Dicas-L ·  NoticiasLinux ·  SoftwareLivre.org ·  [mais] ·  Efetividade ·  Linux in Brazil ·  Floripa  

Sun diz que está prestes a cumprir a promessa de lançar o Java como código aberto

A Computerworld relembra: cerca de 12 meses após receber a promessa de abertura o código do Java, a indústria (juntamente com a comunidade) ainda está por ver esta plataforma lançada sob uma licença livre - mas um representante da Sun voltou a afirmar que a liberação prometida está para ser lançada.

Repetindo uma frase de um resumo semanal do BR-Linux em outubro passado, 'A primeira vez que eu li este mesmo anúncio redigido como fato, e não como especulação, foi em julho de 2005. E a cada vez que o tema volta à imprensa, eu lembro dos Teletubbies dizendo "De novo!"'


De novo!


O representante em questão desta vez é Simon Phipps, que em um contato com a imprensa durante compromissos seus em Sidney, afirmou que "a Sun está a dias ou semanas de um Java completamente código aberto". Mas a revista acredita que tanto a comunidade do Java quanto a do código aberto têm razões para permanecerem céticas quanto a datas mencionadas pela Sun, dado o seu histórico.

Saiba mais (linuxworld.com.au).

Comentários dos leitores

Os comentários abaixo são responsabilidade de seus autores e não são revisados ou aprovados pelo BR-Linux. Consulte os Termos de uso para informações adicionais. Esta notícia foi arquivada, não será possível incluir novos comentários.
Comentário de Paulo Pontes
no sun tech days (mes: no sun tech days (mes passado) foi comentado que o anúncio será feito na javaONE (acho que no fim do mês).

mas mesmo isso vai ser só uma formalização pois a sun já está com o projeto openjdk e o glassfish (o application server) totalmente abertos. Até as principais IDEs para java são abertas (Netbeans e Eclipse)

isso sem contar que java sempre foi open source (que é diferente de livre). A formalização do uso da GPL é mais para satisfazer ambições dos xiitas que para causar alguma mudança.
Comentário de llp
De acordo com a OSI, que: De acordo com a OSI, que mantém a definição de Código Aberto (Open Source), o JAVA não é Open Source.
Comentário de brain
open source: Paulo, de acordo com a própria Sun e com a Open Source Inititive, a licença corrente do Java não é open source, embora ofereça algumas liberdades.

E a empresa mencionou diversas razões pelos quais é interesse dela passar a usar uma licença de código aberto, mas nenhuma delas menciona a idéia de agradar a alguma comunidade religiosa. Para citar Rich Green, o vice-presidente para software da companhia na época de um dos anúncios de abertura no ano passado, a medida tem como um de seus objetivos a adoção maior do Java, pela inclusão dele em diversos programas de código aberto da indústria. Me parece que o benefício disso para o próprio Java supera qualquer interesse em agradar grupos religiosos.
Comentário de fzero
Ha duas coisas interessantes que podem sair disso.: A primeira - que muita gente acha besteira, eu sei - é uma versão decente e oficial de um compilador Java para código nativo. Sem a dependência de uma máquina virtual, o Java poderia se estender a várias áreas onde a performance é essencial.

É verdade que o que Java já é usado para algumas aplicações multimídia, mas veja bem: se já é razoavelmente rápido agora, imagine isso rodando sem a camada de abstração da JVM no meio! O bicho ia voar.

A segunda é praticamente o inverso, mas bem interessante também: a abertura da máquina virtual pode permitir que outras linguagens possam compilar código para o bytecode da JVM.

Já existem algumas implementações de outras linguagens em Java - Jython e jRuby para citar duas - mas elas são apenas isso: re-implementações em Java. Isso adiciona uma camada de tradução no meio que torna tudo mais lento. Imagine acessar *diretamente* a máquina virtual através de Python, Ruby, PHP, (insira sua linguagem preferida aqui) com um código compilado para a JVM tão otimizado quanto o do Java. Isso seria exatamente o que a MS tentou fazer até agora sem sucesso: uma plataforma praticamente universal para rodar diversas linguagens usando um bytecode comum.

Se isso acontecer mesmo, vai ser lindo. :-)
Comentário de Paulo Pontes
sem me alongar em outros: sem me alongar em outros pontos pq já são 23:30 e tou com sono...

"a medida tem como um de seus objetivos a adoção maior do Java, pela inclusão dele em diversos programas de código aberto da indústria."

traduzindo do português corporativo:

"se a gente adotar a GPL e formalizar como código aberto, mesmo as distros mais "puras" não terão argumento contra o seu uso e mesmo a inclusão da JRE no CD de instalação, só com isso ganharemos uma base instalada gigantesca."

não estou dizendo que isso não tem benefícios, é ótimo para o Java e para o linux. Mas o desejo de mudança de licença foi criada pela própria comunidade que não viu que na prática funcionava da mesma forma bem similar a uma licenca livre como a GPL. O temor da Sun que fez com que levasse tanto tempo para adotar a GPL era a possível criação de forks que não fossem compatívei com os bytecodes existentes.

Comentário de llp
"se a gente adotar a GPL e: "se a gente adotar a GPL e formalizar como código aberto, mesmo as distros mais "puras" não terão argumento contra o seu uso e mesmo a inclusão da JRE no CD de instalação, só com isso ganharemos uma base instalada gigantesca."

1) antigamente NÃO ERA PERMITIDO redistribuir o java.
2) as distribuições não possuem nem o direito de aplicar patches de segurança.

"não estou dizendo que isso não tem benefícios, é ótimo para o Java e para o linux. Mas o desejo de mudança de licença foi criada pela própria comunidade que não viu que na prática funcionava da mesma forma bem similar a uma licenca livre como a GPL. O temor da Sun que fez com que levasse tanto tempo para adotar a GPL era a possível criação de forks que não fossem compatívei com os bytecodes existentes."

A estrutura de desenvolvimento do JRE é MUITO diferente das comunidades de Software Livre, basta você ter participado de uma para perceber claramente o que você pode ou não fazer com um software livre e não pode com o JRE.

Acho que a menor preocupação da SUN foi criação de forks incompatíveis. temos milhares de casos em softwares livres comprovando o oposto, até pq, uma versão incompatível não seria java, já que para usar o nome java tem que passar num testcase.
Comentário de silveira
Suspense: Isso é bom, cria um suspense. Devíamos fazer uma festa dessas que são feitas quando sai uma versão nova do gnome e etc. Uma festa do laçamento do Java GPL :D Uma pizza não ia ser nada mau.
Eu cada vez mais me reaproximo do Java apesar das nossas desavenças sintáticas.

--
Silveira Neto - Fortaleza-CE.
www.eupodiatamatando.com

Comentário de Paulo Pontes
milhares de casos de: milhares de casos de software live, mas na plataforma java já houve caso de fork incompatível e que usava o nome de Java.

A JVM da Microsoft se dizia Java e seu código não era 100% compatível com a JRE padrão. Isso acabou indo para os tribunais e levou longos anos para se "resolver" (entre aspas, pois até hoje tem gente que usa a msjvm). Logo eu não consigo criticar a SUN por ser cautelosa...

imaginem se uma kvm (VM para dispositivos embarcados) como essa http://lejos.sourceforge.net/,pega. É um projeto brilhante, mas que é um fork incompatível com as KVMs padrão.


Comentário de Paulo Pontes
Complementando: segundo as palavras de um dos palestrantes do Sun tech days, a visão da SUN é que o Java já está consolidado para aplicações web e mobile, e que o foco do java 6 será desktop.
coisas antes só acessíveis via JNI agora vão poder ser feitas com código 100% java. Uma besteira, mas que exemplifica isso é o trayicon, que agora está disponível para os desenvolvedores java (http://www.xandrix.com.br/blog/2006/12/27/icone-no-system-tray-com-o-java-6/).

Devido a este foco, é do interesse da Sun que a JRE já venha junto com o SO...


Comentário de marcosalex
-- A licença atual da Sun: -- A licença atual da Sun já permite isso, só não é GPL. Aliás, o J2ME já é GPL, assim como o compilador Java. Faltam o J2SE e o J2EE.
Haskell developer
Comentário de silveira
trayicon: Que bom que já tem trayicon.
Uma vez eu vi uma artigo de umas 10 páginas do cara usando JNI e o escambau só para fazer isso. Claro que sem antes mandar a portabilidade para o saco.

--
Silveira Neto - Fortaleza-CE.
www.eupodiatamatando.com

Comentário de leandro
Já faz uns 4 anos que eles: Já faz uns 4 anos que eles (sun) estão inventando desculpas sem pé nem cabeça pra abrir as pernitas.

Comentário de Copernico Vespucio
Por que Java nativo é besteira:: Compilador Java para código Nativo Linux já existe, o GCJ. A única coisa que faz com que ele não funcione 100% é que as bibliotecas da API são baseadas no GNU-Classpath, que não oferece uma implementação completa.

Ao compilar um aplicativo java como código nativo, vc. perde a portabilidade, sendo que no entanto ele continuam rodando no esquema de máquina virtual.

Sim, existem até algumas vantagens (como maior estabilidade e resistência a erros) em utilizar uma máquina virtual mesmo em uma única plataforma. Mas vamos e venhamos: aplicação com máquina virtual que só roda em uma plataforma operacional é uma impropriedade semelhante ao .NET...

Ao compilar java nativamente, vc. perde a maior vantagem da plataforma para ganhar pouca coisa em troca no quesito performance.

Porque "pouca coisa"? Porque o próprio interpretador Java já lança mão de um recurso denominado JIT (Just In Time compiler: compilador de tempo de execução). Quando vc. roda uma aplicação Java o interpretador faz um profiling básico para determinar quais são os blocos de código usados mais freqüentemente e trata de compilá-los para nativo e guardar o resultado em um cache (sem mexer no bytecode original).

Quanto mais vezes vc. roda a mesma aplicação, mais oportunidades vc. dá para o "profiler" e mais blocos são compilados nativamente, preservando no entanto a portabilidade do bytecode.

É por isso que muita gente acha o gcj besteira. A performance ganha não paga o preço da portabilidade.

Se é uma aplicação 100% nativa e não portável que vc. quer, melhor usar uma plataforma também 100% nativa.
Comentário de Copernico Vespucio
Desculpas? Eu diria explicações.: Havia uma tonelada de código a ser relicenciado, oriundo de uma infinidade de fontes diferentes. Relicenciar não é possível, dentro da lei, a menos que se faça um trabalho de revisão de todo esse código e se contate todos os autores (solicitando a mudança de licença do código ou mesmo, se for o caso, comprando os direitos de licenciamento).

Isso custa dinheiro, que eu tenho certeza de que vc. não pagaria. Isso também custa tempo.

Em uma empresa como a Sun vc. precisa justificar esse preço.

Por isso foram feitos diversos anúncios para medir os resultados que poderiam ser obtidos em cada etapa do processo (e também ver se os inimigos da plataforma não começam a comemorar demais).

Foi a mesma coisa com o OpenSolaris. E hoje tanto a implementação do Java Hotspot quanto do principal SO deles estão disponíveis.

Finalmente, não se trata de "abrir as pernas". Trata-se de um processo que beneficiará tanto a comunidade de informação quanto a empresa.
Comentário de fzero
Você não entendeu.: Eu estava falando de ELIMINAR COMPLETAMENTE a máquina virtual do meio do caminho. Código nativo de verdade, saca? Igual ao que você consegue programando em C++.

O Java não precisa estar necessariamente amarrado a algum tipo de máquina virtual para funcionar. É assim *agora*, mas não precisa ser desse jeito até o fim dos tempos.
Comentário de Copernico Vespucio
Então...: Vc. está falando de aproveitar só a *linguagem* java, não a plataforma.

Se eu não me engano, também isso já existe a algum tempo (a especificação da linguagem é pública desde o início). Compiladores da *linguagem* Java para código nativo.

Daí seria só vc. pegar o fonte de todas (ou ao menos as que vc. usa na aplicação) as bibliotecas da API escritas em Java (do GNU-Classpath ou do OpenJDK), e compilar/linkeditar tudo junto com o fonte da sua aplicação. Ou então compilar as bibliotecas como .so ou coisa parecida, caso o compilador usado permita isso.

Mas aí eu pergunto: o que nesse arranjo apresenta vantagens em relação a plataformas nativas, como C++? Muito, muito pouco, eu diria. Uma linguagem o risco da aritmética de ponteiros, legal. Mas Eiffel e várias outras já são assim.

E essa não é uma solução bem acabada. Uma parte da Java API assume que se está trabalhando em uma plataforma portável e dentro de uma VM (exemplos: System.gc(), a classe java.lang.Runtime, a package de instrumentação através de MBeans, etc). Fora desse contexto, muitas coisas perderiam o sentido, mas deveriam ser implementadas por questão de compatibilidade.

No frigir dos ovos, é uma "gambiarra" que elimina as maiores vantagens sem oferecer nada em troca do que já existia em plataformas nativas.

Java (a plataforma, não a linguagem) foi criada para resolver um problema recorrente: oferecer portabilidade com segurança e robustez. Ela é boa nisso.

Graças ao sucesso disso, foi criada uma grande comunidade em torno dela, dentro e fora da indústria, e um processo para gerí-la (JCP), que não tem paralelos em nenhuma outra plataforma de programação existente. Nisso também ela é boa.

Transformá-la em uma imitação de plataforma nativa não é produtivo. O melhor a fazer é o que já está sendo feito: investir cada vez mais em otimização e compiladores em tempo de execução. A cada versão a performance de Java fica mais próxima do código nativo puro, e em mais áreas.

Para aplicações que sejam prejudicadas pelo esquema de coleta automática de lixo da JVM, há duas opções conforme o caso:

a) Simplesmente desligar ou não implementar a coleta. O programador deve ter consciência de que os objetos que ele criar não serão removidos até que a sessão da JVM termine. JMe, JavaCard e várias JVM para controle de robôs (como Lego Mindstorms) trabalham assim. A baixa demanda de objetos para essas aplicações permite essa medida.

b) Se as coletas podem acontecer, mas precisam ser previsíveis (por exemplo: sistemas de controle de tráfego aéreo, sensores de precisão, etc), usa-se uma JVM aderente à JSR 1 (sim, é bem antiga!): Real Time Specification for Java (RTSJ).
Comentário de Copernico Vespucio
Lejos: Na verdade, a VM do LeJos é compatível com a especificação *Java* em si, observadas as suas características particulares.

Ela só não adere às especificações KVM existentes (CDC, CLDC). E nem precisa, porque robôs do Lego não são dispositivos embarcados comuns.
BR-Linux.org
Linux® levado a sério desde 1996. Notícias, dicas e tutoriais em bom português sobre Linux e Código Aberto. "A página sobre software livre mais procurada no Brasil", segundo a Revista Isto É.
Expediente
Sobre o BR-Linux
Enviar notícia ou release
Contato, Termos de uso
FAQ, Newsletter, RSS
Banners e selos
Anunciar no BR-Linux
BR-Linux apóia
LinuxSecurity, Tempo Real
Suporte Livre, Drupal
Verdade Absoluta
Pandemonium
Efetividade, Floripa.net
sites da comunidade
Ajuda
Moderação
Flames: não responda!
Publicar seu texto
Computador para Todos
Notícias pré-2004
Tutoriais, HCL pré-2004