Evangelista da Sun diz que o Java pode virar código aberto... eventualmente

Apesar de na~o ser fa~ do JAVA e muito menos programar em JAVA. A comunidade Free Software vai ganhar muito com isso. Esperamos que se confirme isso.
Ate`+

A discussão sobre abertura do código da JVM é simplesmente inóqua. A JVM não é nada mais que um processador emulado em software. Ninguém pede para a Intel abrir o "código" do seu processador. Está todo mundo feliz rodando software livre sobre um processador proprietário.

A Sun jamais vai abrir o código de sua JVM. Esqueçam. Façam software livre em Java para rodar na JVM da Sun como vocês escrevem programas livres em C para rodar em Intel. E vão cuidar da vida.

Ué, Cândida. Mas se a Sun diz que vai abrir, você quer que a gente faça o que? Não noticie?

O que a gente vai ganhar com a "abertura do Java"? Abertuda do Java quer dizer liberar o código do JVM? Mas já não tem uma VM opensource?

sem falar muito pois sou iniciante em java,
agora,
JVM é MUITO diferente de J2EE, J2SE e J2ME,
JVM é um runtime do java para executar programas, o compilador é ouuutra coisa

Desculpe discordar mas JVM é JVM...

J2EE - Servidores (Enterprise)
J2SE - Desktops (Standart)
J2ME - Portateis (Acho que seria essa definição Palms, Celulares, etc... Acho que até aquele "anel java" entra nessa)

Cada uma delas tem suas "classes" necesárias, por exemplo: J2ME não precisa da classe "mouse" porque em um celular não tem "mouse", embora precise de classes adicionais como "conexão com agenda" (ainda não, :P), a JVM base se mantém a mesma para todas as situações.
Existe o compilador que compila a JVM para a plataforma em questão, e o JIT que é o compilador "Just in Time" que está dentro da JVM.
A JVM é feita seguindo a especificação (que é aberta) a qual outras JVMs (IBM, Microsoft) também se baseiam.
As vantages para abertura da JVM da SUN seriam:
-Melhorias gerais no codigo, performace, etc (acho que vocês conhecem como funciona)
-Uma tecnologia livre contra o .NET
-Satisfação pessoal de Richard Stallman(Alguem lembra como ele foi chatinho na questão da biblioteca QT)?

O que acontece são alguns problemas com as classes citadas que não fazem parte especificação JVM e são usadas por qualquer programador e daí é um trabalho de adivinhação bem complicado...

Também sou iniciante, mas estou aprendendo a falar Javanês e Oracle para no futuro contribuir com Compiere principalmente no brasil (www.compiere.org)

Abraço

Pessoal, esse povo aqui (http://www.nwfusion.com/news/2004/0604sunnode.html) diz q não é bem isso que vai acontecer.

Ahn, qto ao link acima... saiu com parênteses sobrando
http://www.nwfusion.com/news/2004/0604sunnode.html

Sobre o comparativo JVM/Processador Intel:

Por mais que se sonhe em termos um processador que execute bytecode Java nativamente essa situação ainda não se tornou realidade.

Ok. Esclarecido esse ponto vamos ao seguinte. A especificação dos processadores Intel é aberta, tanto que a AMD produz microchips totalmente compatíveis.

Esclarecido esse ponto também vamos fazer o questionamento que a FSF (mais notadamente o RMS) teve quando criou a fundação: Qual é o custo de você replicar hardware e qual o custo de você replicar software?

A JVM da Sun é Software. E como software deve ser livre a JVM da Sun deve ser livre também. Não existe dois pesos e duas medidas.

*Hoje* (não sei o amanhã), quando fazemos software livre em Java estamos obrigando pessoas a ficarem aprisionadas ao software proprietário (JVM) para que elas possam usá-lo (a menos que façamos o software pensando em rodá-lo em alguma implementação livre, porém incompleta, da JVM).

É isso que o RMS fala no artigo "Livre mas algemado: A armadilha Java". No entanto esse artigo conclama os desenvolvedores Java a auxiliarem nos trabalhos de uma implementação livre da JVM. Até lá, as únicas JVMs 100% compatíveis com a especificação (que é livre) são sim proprietárias.

> Ué, Cândida. Mas se a Sun diz que vai abrir, você quer que a gente faça o que? Não noticie?

Eu não falei para não noticiar. Continue noticiando. Se você não noticiar, não tem como a gente comentar o conteúdo, ó pá. :P

O papo da Sun é ir cozinhando o galo enquanto a comunidade vai percebendo aos poucos (ou se acostumando com o fato de) que não há nenhuma necessidade de se abrir o código-fonte da JVM da SUN. As especificações da JVM estão abertas, qualquer um pode construir a sua, só não pode usar o nome Java sem a licença deles. Que mais queremos? Será que poderíamos fazer o mesmo com os processadores da Intel? Duvido.

A Sun já corre o risco de criar sua própria concorrência liberando as especificações da JVM. Se abrir o código, é melhor dar adeus ao negócio Java. E eu ainda suspeito que muita tecnologia embutida no código JVM da SUN, como ocorre em toda iniciativa industrial de grande porte como é o Java, está sujeita a patentes e acordos cruzados de licenciamento. Abrir o código seria quebrar contratos. Mas essa explicação não apela à comunidade de software livre, então o negócio e ir levando, como eles fazem com esses anúncios aí.

Ah, e obrigado por me chamar pelo meu nome verdadeiro. :)

Apenas relembrado o caso da biblioteca QT x Richard Stallman:
Lutou-se um monte para tornar a biblioteca livre e se conseguiu isso parcialmente, pois é uma licença dupla, ele foi um dos percursores dessa briga, mas mesmo após ter ganhado a briga ele disse que a QT só seria livre se a Trolltech pedisse desculpas. (Achei escroto! Isso não quer dizer que não admire Stallman pelo seu trabalho).

Segue citação em que me baseio, que é de Roberto Teixeira (Conectiva):
"Fiquei tentado, mas o que me levou mesmo ao KDE foi quando a Trolltech, empresa que desenvolve a Qt, decidiu liberar a Qt sob a GPL para acabar com a velha briga FSF vs. KDE, e o Stallman disse que mesmo assim o KDE não poderia ser considerado um software livre enquanto o projeto não pedisse desculpas a todos os desenvolvedores do mundo por anos de desserviço. Achei isso uma afronta e um abuso de poder e na hora comecei do GNU Emacs para o XEmacs e passei a usar KDE"
Link original: http://www.revistadolinux.com.br/ed/026/assinantes/entrevista.php3

Qualquer divergência favor postar aqui e não me mandar e-mail particular dizendo que sou "anti-linux" por não concordar com UMA atitude de Stallman (Ele não é Deus, e Torvalds não é o messias, acredite se quiser, :P)

Abraços

Sobre o comparativo JVM/Processador Intel:

>Por mais que se sonhe em termos um processador que execute bytecode Java nativamente essa
> situação ainda não se tornou realidade.

Isso não anula o princípio da comparação. A JVM atua como um processador. O conceito de Virtual Machine é emular em software uma arquitetura de hardware. Se ninguém fez um processador que execute bytecodes Java, é outra história, mas isso é perfeitamente possível e, inclusive, fazia (faz) parte dos planos originais do Java.

Portanto não estamos comparando alhos com bugalhos. Estamos comparando dois ambientes proprietários sob o qual se executa programas.

> Ok. Esclarecido esse ponto vamos ao seguinte. A especificação dos processadores Intel é
> aberta, tanto que a AMD produz microchips totalmente compatíveis.

A Intel LICENCIA as especificações de seus processadores para a AMD, se não estou enganado. Não sei se eu posso cozinhar um chip Intel e sair vendendo por aí sem ser processado por quebra de patente. É melhor você verificar.

> Esclarecido esse ponto também vamos fazer o questionamento que a FSF (mais notadamente o
> RMS) teve quando criou a fundação: Qual é o custo de você replicar hardware e qual o custo
> de você replicar software?

Se o assunto for custo, a argumentação morreu. A JVM é distribuída de graça.

> A JVM da Sun é Software. E como software deve ser livre a JVM da Sun deve ser livre também.
> Não existe dois pesos e duas medidas.

Você tocou no ponto da minha argumentação: "não existe dois pesos e duas medidas". Você já projetou um processador? É software! A diferença é que as instruções ficam solidificadas na dopagem do substrato do semi-condutor. Então se exigimos da Sun que abra sua JVM, porque não fazemos o mesmo com a Intel?

>*Hoje* (não sei o amanhã), quando fazemos software livre em Java estamos obrigando pessoas
> a ficarem aprisionadas ao software proprietário (JVM) para que elas possam usá-lo
> (a menos que façamos o software pensando em rodá-lo em alguma implementação livre, porém
> incompleta, da JVM).

Invertendo a lógica: se estamos felizes com a Intel controlando nossas vidas, porque enchemos o saco da Sun?

> É isso que o RMS fala no artigo "Livre mas algemado: A armadilha Java". No entanto esse
> artigo conclama os desenvolvedores Java a auxiliarem nos trabalhos de uma implementação
> livre da JVM. Até lá, as únicas JVMs 100% compatíveis com a especificação (que é livre)
> são sim proprietárias.

Até nisso RMS é coerente. Ele não exige que a Sun abra o código, como nunca exigiu que ninguém abrisse o código de nada. Ele criou um movimento para escrever programas livres alternativos.

Portanto, disperdiçamos nossa energia quando nos mobilizamos para insistir que a SUN abra o código de sua JVM. Canalizemos esse esforço para escrever um JVM livre alternativa e deixemos a SUN em paz.

> o Stallman disse que mesmo assim o KDE não poderia ser considerado um software livre
> enquanto o projeto não pedisse desculpas a todos os desenvolvedores do mundo por anos de
> desserviço.

Então taí. Para a SUN é melhor do jeito que está. Agüenta a crítica presente, aproveita pra ficar na mídia e vai levando a comunidade em banho-maria. Se a SUN abrir o código, Stallman vai tripudiar em cima e execrar a SUN em praça pública.

A JVM jamais vai ser aberta. Fim da discussão.

Osni,

Desculpa mas você está citando o que o Maragato falou do Stallman e não o que o Stallman falou. E pelo que eu me lembre, não foi isso que ele disse: ele tocou no ponto legal de que a mudança de software da biblioteca implicaria em necessariamente uma revisão da licença de cada software que usava a QT para ser compatível com a nova licença. Claro, foi mal-compreendido e achincalhado por todos (pra variar), inclusive e principalmente pela equipe do KDE.

Você tem a referência do Stallman falando isso? Acho que assim como tem zelotas de qualquer tipo, em fóruns de software livre tem gente que se preocupa tanto em mostrar que tem "pé no chão" que adora rechaçar qualquer afirmação do Stallman como idealista ou mesquinha, sem prestar atenção na real coerência dele.

"Reabrindo a Discussão"
Cândida Erêndira:
A satisfação de Stallman não era a unica vantagem com a abertura do codigo.
Apenas coloquei essa informação para lembrar onde começou essa história.

Abraços

Patola:
Realmente me fixei apenas no que o Ricardo (Conceito de confiabilidade de fonte) falou a respeito e lembranças de boatos na epoca.
Acho que vou pedir pro Ricardo de onde ele tirou esse comentario, mas fica minha "mea-culpa" de não ter verificado mais ao fundo. Alguem tem o e-mail dele?

Abraço

Ops.. Troquei Roberto por Ricardo...

Como desenvolvedor Java, espero que a Sun NÃO torne a especificação Java GPL. Senão, a IBM e outras vão dar um embrace sem volta (como a MS tentou fazer com o Java antes de ser processada). E, de novo, como um desenvolvedor Java, espero sim que o Stallman termine sua versão GPL totalmente compatível com a especificação, porque afinal, Kafee e Blackdown não são 100%.

> Como desenvolvedor Java, espero que a Sun NÃO torne a especificação Java GPL. Senão, a IBM e
> outras vão dar um embrace sem volta (como a MS tentou fazer com o Java antes de ser
> processada).

Eu tenho uma bola de basquete, outra de vôlei. Aposto minhas duas bolas que o que impede a Sun de abrir o código é a IBM, entre outras coisas de que já falei acima.

Veja, a IBM tem uma licença da Sun para usar Java. Quais devem ser os termos dessa licença? Não sabemos, mas podemos especular. A IBM tem uma JVM compatível e melhor do que a JVM da SUN. Seria contra-producente para a IBM escrever a JVM do zero, já que paga a licença.

Minha aposta: a licença da IBM deve permitir ter acesso ao fonte da JVM da SUN. A SUN desenvolve uma versão de referência, e a IBM faz a otimização. Muito código da JVM da SUN deve fazer parte da JVM da IBM.

Abrir a JVM da SUN vai obrigar a IBM a abrir também, destruindo o plano de negócios montado pelas duas empresas, juntamente com as outras que gravitam em torno desse acordo.

> Minha aposta: a licença da IBM deve permitir ter
> acesso ao fonte da JVM da SUN. A SUN desenvolve
> uma versão de referência, e a IBM faz a
> otimização. Muito código da JVM da SUN deve
> fazer parte da JVM da IBM.

> Abrir a JVM da SUN vai obrigar a IBM a
> abrir também, destruindo o plano de negócios
> montado pelas duas empresas, juntamente com as
> outras que gravitam em torno desse acordo.

Então a IBM, por esse raciocínio, deveria estar interessada em evitar que a Sun abra o código da JVM? Mas segundo as notícias, é justamente a IBM que pede à Sun que abra o código. A IBM estaria fazendo isso de fachada?

Outra: a Sun abrir o código da JVM dela não quer dizer automaticamente que as licenciadas têm que abrir também - depende muito da licença. E se não me engano, além de tudo, prevalece o uso anterior - a IBM não precisaria abrir automaticamente um código que antes era proprietário da Sun, e pelo qual ela pagou assim, ou seja, tinha uma licença (pra IBM) que permitia a ela velar o código. Apenas as novas versões da JVM, dependendo da licença, impediriam os licenciados de mantê-la fechada, *SE* fosse uma licença tipo GPL. Se fosse BSD não teria problema nenhum. E ainda podia ser dual-licensed, GPL mas com permissão para quem paga ter uma implementação otimizada fechada.

A idéia é: há muitos cenários possíveis de "abertura" do código. Não dá pra generalizar sem saber qual seria o cenário escolhido.

É incrível como a dependência de tecnologias proprietárias leva à insegurança da comunidade. Seria muito bom que a Sun liberasse o java, mas eu acredito que isso não ocorra, ainda mais com a crescente utilização desta ferramenta em ambientes corporativos.

Eu só não entendo por que não se usa Python ao invés de java. Além de ser uma linguagem elegante, multiplataforma, poderosa e de sintaxe simples, já nasceu aberta!

> Então a IBM, por esse raciocínio, deveria estar interessada em evitar que a Sun abra o código da JVM? Mas segundo as
> notícias, é justamente a IBM que pede à Sun que abra o código. A IBM estaria fazendo isso de fachada?

Patola, você é um cara inteligente. Deixo para você chegar a uma conclusão.

> A idéia é: há muitos cenários possíveis de "abertura" do código. Não dá pra generalizar sem saber qual seria o cenário
> escolhido.

Isso tudo seria lindo se entre essas empresas não houvesse um emaranhado de licenças cruzadas.

Para simplificar, há licenças da IBM dentro da JVM da SUN e vice-versa. Se a SUN abrir o código unilateralmente, vai quebrar contrato. Mas eu suspeito que há licenciamento de outras empresas. A SUN nunca deu essa justificativa, porque a pergunta seguinte será "que empresas são essas"? Revelar isso vai expor a estratégia por trás da iniciativa Java.

Java é um indústria inteira, não só uma linguagem.

Recebi um email sem maiores explicações de um tal de osni hoje à tarde, simplesmente me dizendo para entrar neste site para prestar esclarecimentos. Depois de tentar conseguir mais informações em relação ao que diabos o indivíduo queria, tive de vir para cá ver do que se tratava e confesso que fiquei deveras decepcionado... Vocês já ouviram falar em Google? :-)

Bom, uma rápida pesquisa no Sr. Google e:
http://linuxtoday.com/news_story.php3?ltsn=2000-09-05-001-21-OP-LF-KE
http://www.kde.org/announcements/rmsresponse.php

Mensagens do maleta mor (não o patola, o stallman :) para a lista da KDE e.V. eu não tenho mais, talvez alguém por aí tenha, mas de qualquer modo isto aconteceu em 5 de setembro de 2000, quase quatro anos atrás!! Vocês não tem mais nada para fazer, não? :-)

Pelo jeito ninguém aqui acompanhou o movimento "chega de conversa" iniciado no 5o. FISL, né? Mas a vida é de vocês, e se o esquema for só ficar na conversa mesmo, pelo menos discutam algo com menos de 1 ano de idade, e POR FAVOR, me deixem fora disso, pois eu tenho mais o que fazer. Tá louco... :)

Ué, mas esclarecimentos do que? Eu tenho mais o que fazer sim, quem é esse cara que te chamou?

> Eu só não entendo por que não se usa Python ao invés de java. Além de ser uma linguagem elegante, multiplataforma,
> poderosa e de sintaxe simples, já nasceu aberta!

Porque não conta com apoio industrial, como o Java. O Java nasceu para criar uma indústria inteira baseada em software, de que participam várias empresas. O Python só vai competir com Java se acontecer de a indústria se revoltar contra o Java. Isso é improvável, porque a própria indústria que se vale do Java, é a mesma que o controla (JCP).

Um cara chamado Osni. Sobre o "não tem nada a fazer?", eu me refiro ao pessoal da subthread sobre o stallman/kde/eu(!?). Nada a ver com a discussão do Java que, aliás, eu não li.

Peço desculpas mesmo por te-lo chamado/incomodado, me precipitei.
Faltou google mesmo... :P

Mas não venho aqui só pra jogar conversa fora, eu venho aqui para aprender, me informar e baseado nisso tomar um rumo nesse oceano que nos encontramos.

PS: Eu lhe respondi o e-mail com as informações que pediu.

Abraços

Eu já tive vários problemas com JVM da SUN.
Estar disponível para Windows mas não estar disponível para Linux no mesmo dia, na mesma hora. Bugs no Windows serem diferentes de
bugs no Linux. Desde então abandonamos
em nosso trabalho qualquer desenvolvimento de SL que dependesse da JVM da SUN.
Eu acho um risco desenvolver SL que
dependa da JVM da SUN.
É necessário continuar a dizer as coisas como elas são: Java da SUN não é SL e JVM não é igual
a um processador.

Odair G Martins

Java da Sun não é SL, nem a JVM é um processador. Mas os processadores são proprietários e não nos importamos de rodar nossos programas livres sobre eles.

Você pode ter programas feitos em Java totalmente livres, como é o caso do Compiere, http://sourceforge.net/projects/compiere , em Java e distribuido sob MPL (Mozilla Public License). Um verdadeiro sucesso, um dos softwares mais baixados do Source Forge.

Então a discussão é a seguinte: seja coerente. Vai gastar seu tempo denegrindo o Java por ser proprietário, denigra o Intel, pelo mesmo motivo. Se não se importa com a Intel controlando absolutamente o ambiente de execução de programas, por que vai se importar com o Java? O fato de um ser hardware e o outro ser software não faz absolutamente nenhuma diferença do ponto de vista que realmente conta: controle.