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

De novo II: dessa vez a Sun *afirma* que vai abrir o código do Java

“A empresa está pedindo por manifestações da comunidade sobre como equilibrar o código aberto e a prevenção da fragmentação. Jonathan Schwartz fez o anúncio de que a empresa está planejando liberar o código do Java hoje na conferência JavaOne em San Francisco. 'Não é uma questão sobre se vamos tornar o Java código aberto, agora a questão é como', ele afirmou na abertura do evento.


De novo!

 


Ao liberar o código fonte, a Sun espera atrair um novo grupo de desenvolvedores que anteriormente se recusavam a usar a linguagem por causa da licença, ele informou. O debate sobre a abertura de código do Java tem estado em aberto por anos, e em parte foi alimentado pela IBM. A Sun resistiu a chamados pela liberação do código, em parte por preocupação com a possível fragmentação e o surgimento de forks.
” Veja o texto completo em Sun promises to open source Java - vnunet.com.

Mais: Sun's Pledge To Make Java Open Source Leaves Key Questions Unanswered; Sun will open source Java, embrace Linux on Sparc; Sun: Help Us Open Source Java; Sun further commits to open source Java; Teletubbies . Welcome to Teletubbyland! - PBS Kids; Sun Advances Open Source Strategy at JavaOne

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 philippe
duvida comprensivel: a fragmentação podería ser um problema
Comentário de marcus
Medo infundado: Acho que é um medo bobo. Se fosse assim não existiriam grandes projetos de software livres como Apache, Kernel Linux, etc.
Se ela souber se relacionar bem com a comunidade e assumir o papel de "patricinadora" do projeto, talvez até criando uma Fundação para conduzir, não acredito que vá ter problemas com fragmentação. Pelo contrário, alguns dos esforços que hoje estão pulverizados deixariam de existir, pelo simples não fazer mais sentido manter uma implementação incompletada, com menos recursos, performance, documentação, etc.
Comentário de Dm7
Vocês não entenderam! A: Vocês não entenderam! A intenção deles ao abrir é ver se conseguem fazer o que originalmente queriam, usar essa tecnologia para empregá-la em eletrodomésticos!!

Comentário de nemesis
abrindo ou não, continua: abrindo ou não, continua uma tecnologia deplorável e lamentável...

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

Comentário de Chuc
Cite argumentos técnicos: Cite argumentos técnicos que comprovem isso.

Falar por falar não vale.
Comentário de Peter Parker
JVM: Se for liberar a JVM sob GPL, não acredito muito em fragmentação. Agora, a IBM deveria parar de ficar apontando o dedo e liberar suas ferramentas Java também sob GPL, como o Websphere.
Comentário de Penetro
Forks, Runtime: Creio que o grande receio da SUN é que apareça um Fork semelhante ao OpenOffice, que praticamente apagou o "produto" StarOffice deles. Quem mandou eles abrirem e depois fecharem o código?
Mas refletindo sobre o StarOffice, fica no ar outra pergunta: "Não é uma questão sobre se eles vão ou não tornar o Java código aberto, agora a questão é por quanto tempo'?.

off-topic
Eu, particularmente acho que o conceito do Java como plataforma é idéia muito legal, mas hoje em dia o Java ainda é apenas um Runtime , e a menos que você esteja disposto a sacrificar eficiência em favor de um bom grau de portabilidade, ele não apresenta vantagem real sobre qualquer outra linguagem.


[]s
Penetro

Comentário de Penetro
Forks, Runtime: Creio que o grande receio da SUN é que apareça um Fork semelhante ao OpenOffice, que praticamente apagou o "produto" StarOffice deles. Quem mandou eles abrirem e depois fecharem o código?
Mas refletindo sobre o StarOffice, fica no ar outra pergunta: "Não é uma questão sobre se eles vão ou não tornar o Java código aberto, agora a questão é por quanto tempo'?.

off-topic
Eu, particularmente acho que o conceito do Java como plataforma é idéia muito legal, mas hoje em dia o Java ainda é apenas um Runtime , e a menos que você esteja disposto a sacrificar eficiência em favor de um bom grau de portabilidade, ele não apresenta vantagem real sobre qualquer outra linguagem.


[]s
Penetro

Comentário de Passante Curioso
Mais provável eles: Mais provável eles liberarem como LGPL.
Comentário de Passante Curioso
Certificação: Eles não tem um teste que certifica se uma máquina virtual é Java Complaint? Eles não tem um nome forte no mercado? Eles não podem simplesmente liberar o código, mas manter o controle sobre a marca?
"Se você quer usar o java que o mercado usa e nós aprovamos, use os que tem o selo de garantia Sun/IMETRO!"
Se quiser customizar, use os outros ;)

Comentário de Peter Parker
OO.org: Penetro, a Sun foi quem liberou o código do StarOffice para criarem o OpenOffice.org, e não foi feito sob revelia.
Quanto a segunda parte, não vou entrar no mérito.
Comentário de hamacker
Se nao existisse OpenOffice: Se nao existisse OpenOffice duvido que usuarios e distribuicoes Linux empacotassem StarOffice (fechado).
Acho que seria o contrário, se tivesse Liberado logo o StarOffice como opensource (GPL ou nao) duvido que OpenOffice faria sentido. O que a Sun fez, fez igual a Borland com o Interbase : lança a sua versao opensource e por falta de apoio e continuidade a comunidade é induzida a fazer um fork dele, no frigir dos ovos quem ganha é o fork e depois de algum tempo muita gente nem se lembra mais quem foi o criador original.

O ideal é ser opensource desde inicio e se for bem apoiado não é necessario temer o fork.

Sei que a Sun contribui ativamente para o OpenOffice (diferente do que a borland fez), mas faz isso apenas para tambem receber as modificacoes e aplica-la no StarOffice, uma duplicação de esforços que só a Sun vê vantagens.
Comentário de Paulo Pontes
abrir sob a licensa GPL seria um erro mortal: Alguém aí se lembra quando a MS tinha uma "Java" VM? Coloco as aspas porque qualquer desenvolvedor que fizesse algo além do Hello World tinha sérios problemas de compatibilidade, matando o "write once, run anywhere".

Com a implementação da SUN liberada para outras empresas (para desenvolvedores já estava faz anos) a MS poderá fazer o fork e dizer que é um "java otimizado para windows" que virá junto com o SO (sem compatibilidade com as java vm padrão). Todo mundo vai usar o otimizado para windows, pois 90% dos desktops são windows mesmo e quando perceber a portabilidade já era...

Como a principal vantagem do java sobre o .NET é a portabilidade, uma vez acabada a portabilidade do Java, todo mundo vai migrar para php e .NET.

Teremos mais um caso de tecnologia superior sendo vencida por tecnologias inferiores devido a más decisões administrativas.
Comentário de Penetro
Concordo 100%:
O ideal é ser opensource desde inicio e se for bem apoiado não é necessario temer o fork.


Concondo 100%
[]s
Penetro

Comentário de hamacker
Ao contrário, dentro de: Ao contrário, dentro de pouco tempo a fundação mozilla iria conseguir um Java 100% dentro das especificações e sendo opensource o sun-java iria perder muito espaço, não há como competir um programa fechado versus livre se ambos realizam exatamente a mesma coisa entao todas as distros vao preferir e empacotar a versao livre e com o passar do tempo o sun-java seria esquecido.

Liberando o sun-java como opensource, as distros passam a empacota-las, os projetos GPL atuais que correm para construir um java 100% dentro das especificacoes podem ser descontinuados.

Em sumo, a sun esperou até o ultimo segundo, mas no final acabou fazendo o que todo mundo já sabia que ela um dia iria fazer : liberar o sun-java sob uma licença livre. Nao se engane, a sun tenta salvar o java dela. Ela não faria isso se outros javas estivessem longes do sun-java.
Comentário de Penetro
É preciso ver o contexto da época: Liberar o código do OpenOffice foi uma iniciativa louvável, mas estranhei eles terem fechado o código logo em seguida e anunciado o lançamento de um produto fechado (StarOffice) que àquela época era mais maduro que o OpenOffice.

Hoje em dia, com a maturidade do OpenOffice, nosso referencial muda, e essa atitude (fechar o código) parece não fazer sentido nem diferença.



[]s
Penetro

Comentário de Penetro
Absurdo!: O .NET é prar mim um exemplo típido da insanidade monopolista da MS. É o "Write everywhere, run only here".

Se o .NET só roda e só existe sob windows, pra que um framework (runtime)? Qual a vantagem de uma máquina virtual que só roda em uma plataforma?

Mas com certeza a MS vai querer se aproveitar de alguma maneira...

[]s
Penetro

Comentário de Copernico Vespucio
StarOffice, Java e Forks: Creio que o grande receio da SUN é que apareça um Fork semelhante ao OpenOffice, que praticamente apagou o "produto" StarOffice deles

Isso é um engano. O Star Office nunca foi "apagado". O código do Star Office foi liberado para que a versão grátis do produto não precisasse mais ser mantida pela própria Sun (conseguindo então o marketing do qual o produto precisa, sem custos). Hoje, o diferencial do Star Office é o suporte direto da Sun (praticamente a única diferença entre os dois produtos) e ele é utilizado por clientes para os quais esse suporte faz diferença (como corporações, governos, etc).

A Sun usa a mesma estratégia com o Open Solaris. O produto aberto ajuda a aumentar a adoção da tecnologia e serve como laboratório para testar técnicas que poderão ser usadas no produto comercial no futuro (uma alternativa à tática da M$, que é usar seus clientes pagantes como "cobaias" de novas tecnologias).

Creio que o receio da equipe Green (que é de onde, na Sun, vem esse receio: James Gosling e a turma original que criou a plataforma), é que a abertura do código dê origem a "Java Clones" fajutos por aí, todos tentando forçar um "padrão melhor que o oficial".

Ainda que a licença restritiva original seja ruim, foi ela que salvou o Java da "tática de fagocitose" da M$.

Não vejo cons bons olhos essa "medida populista" da abertura. Isso pq, no caso do Apache Harmony (implementação aberta de Java, já em andamento a pleno vapor), ele tem de seguir as especificações e tem a J2SE "original" como ponto de referência.

A abertura pode ser o que a M$ estava esperando para finalmente destruir a plataforma, ou o que a IBM estava esperando para tomar conta dela. Ter um padrão não adianta muita coisa. O W3C tem padrões fortes e respeitados que são chutados solenemente pela M$ e ganham popularidade via propaganda. Se alguém (M$, IBM) lança um fork com qualidade inferior, despadronizado e o apóia com um marketing extremamente agressivo, perdemos todos nós.

Se a abertura é "inevitável", a comunidade deve atuar com rigor e bom senso para estabelecer com cuidado os termos dela. Não creio que possa ser GPL e nem mesmo LGPL, pois algumas garantias adicionais precisam ser mantidas (por exemplo: se não adere às especificações JCP, ou não passa no TCK, não pode distribuir). Isso não impede que alguém faça sua própria implementação de Java com GPL ou outra licença qualquer (como o Harmony), mas o código da implementação oficial de referência deve ser protegido de práticas predatórias.

Senão é gente lançando produtos "Java" que só rodam sobre aquela JVM específica, que só está disponível para aquele SO específico, como a M$ tentou fazer no passado com o Micro$oft J++.

a menos que você esteja disposto a sacrificar eficiência em favor de um bom grau de portabilidade, ele não apresenta vantagem real sobre qualquer outra linguagem

Além da portabilidade, Java hoje apresenta outros apelos interessantes... Dá pra citar alguns fatores:


  • Uma comunidade muito grande e motivada (J2SE6.0, tocada em sua maioria pela comunidade Java, ficou pronto em menos de 1 ano)


  • Abrangência da plataforma (praticamente não há tecnologia ou plataforma que não conte com uma especificação, produto ou API para suportá-la).


  • evolução baseada em padrões fortes (propostas novas são primeiro votadas, depois especificadas, as especificações exaustivamente revisadas, implementações de referência são feitas com base nas especificações e as IRs são exaustivamente testadas antes de se dar o "sinal verde" para implementações "de produção"). Isso evita a ocorrência de "becos sem saída" nas APIs.



[]s
Comentário de philippe
errado: o StarOffice é tão somente o OpenOffice.org com a garantia da Sun, suporte e manuais. não é nem melhor, nem pior.
Comentário de Copernico Vespucio
"fechamento": O código do Star Office propriamente dito sempre foi fechado. O que aconteceu é que antes ele era distribuído de graça. Não confunda os dois conceitos.

O Star Office fechado foi mantido, a despeito da abertura para o Open Office, pelo mesmo motivo que o Solaris continua fechado, a despeito de existir um Open Solaris.

Tendo uma versão fechada do produto, a empresa garante que a propriedade do código é apenas sua, podendo se responsabilizar sozinha por ele perante a seus clientes. Ela atende aos clientes que vêem vantagem nisso.

É também importante que haja um produto aberto equivalente, por vários fatores. Para atender a outros nichos nos quais a companhia não está originalmente interessada, manter a popularidade do produto, beneficiar o produto fechado com novas idéias, poder fazer contribuições ao produto aberto (que se destinam a serem testadas pela comunidade) antes de usar a mesma tecnologia no produto fechado, etc.

A abertura de código de um produto proprietário, mantendo o produto original, é uma estratégia que permite à empresa ter o melhor dos dois mundos.
Comentário de Copernico Vespucio
O "Sun/INMETRO" poderia ser: O "Sun/INMETRO" poderia ser combatido com práticas agressivas de propaganda apoiando um padrão fajuto, como por exemplo, um ECMA/Java de parte da Micro$oft.
Comentário de Copernico Vespucio
Apache Java: dentro de pouco tempo a fundação mozilla iria conseguir um Java 100% dentro das especificações e sendo opensource o sun-java iria perder muito espaço...

Não ainda a fundação Mozilla, mas o grupo Apache está fazendo exatamente isso, com a ajuda de vários funcionários da Sun que são pagos por ela para participar do projeto. Isso sem precisar que o código original seja aberto.

Para quem acha que o Harmony iria demorar muito, procure se inscrever na lista do projeto. Semana passada, o pessoal lá estava muito animado com a contribuição da Intel de uma JVM de uso interno compatível com o seu hardware. Outros fabricantes, de todos os lugares, estão fazendo doações equivalentes.

O Apache Harmony vai ficar 100% compatível (pq o AG tem o TCK) e será, pelo visto, muito melhor do que a JVM original da Sun (assim como existem alternativas, hoje comerciais, que já são).

A importância da JVM da Sun é ser uma implementação de referência. Um ponto estável, menor denominador comum entre as diferentes implementações alternativas.

A Sun não ganha nada distribuindo a sua implementação da JVM. Ela ganha com produtos compatíveis com a sua implementação. Do ponto de vista dessa empresa, tudo o que importa é a compatibilidade.

Se vc. vai rodar o que ela oferece sobre uma JVM livre ou não, não interessa, contanto que sua JVM continue compatível com os produtos dela.

Se ocorrer qualquer problema de percurso temporário com a implementação livre mais popular, é importante que haja uma implementação de referência confiável para "quebrar o galho" até que a situação se acerte.
Comentário de Copernico Vespucio
Windows VM: Se o .NET só roda e só existe sob windows, pra que um framework (runtime)? Qual a vantagem de uma máquina virtual que só roda em uma plataforma?

Existem algumas, mesmo assim. O gerenciamento automático de memória (simplificando os programas), o isolamento do ambiente externo (prevenindo que o programa dentro da VM prejudique o ambiente operacional de alguma forma, ou vice-versa), etc.

A máquina virtual não atende apenas ao quesito portabilidade.

Programas escritos em .NET (eca!) rodando sobre o Windows são tipicamente muito mais estáveis do que aplicações que rodam diretamente sobre o SO.


Comentário de Copernico Vespucio
exato: Abrir java pela GPL seria um erro mortal
. . .
Teremos mais um caso de tecnologia superior sendo vencida por tecnologias inferiores devido a más decisões administrativas.




Esse é exatamente o ponto.

A GPL e equivalentes são muito boas para produtos finais como o KDE, o Linux.

Essas licenças, por melhores que sejam, não possuem as garantias necessárias para proteger uma plataforma de desenvolvimento (que não se compõe apenas de software ou código, mas de regras, especificações e padrões) e sua comunidade de ataques como esses.
Comentário de Copernico Vespucio
Fragmentação: Se ela souber se relacionar bem com a comunidade e assumir o papel de "patricinadora" do projeto, talvez até criando uma Fundação para conduzir, não acredito que vá ter problemas com fragmentação

No exato momento em que o código abrir como GPL, a M$ e a IBM vão se apresentar como patrocinadores de "seus" projetos, criando fundações e o que mais for necessário para empreender uma guerra de padrões.

Nesse momento, por causa desse anúncio, eles deve estar cruzando os dedos e seus designers já estão fazendo os sites...
Comentário de Copernico Vespucio
Não entendi mesmo...: Não entendi mesmo, pq isso já é feito hoje...

As JVM embarcadas rodam sobre processadores suportados. Basta um fabricante botar um desses processadores em sua batedeira + uma ROM com a JVM e programas e seu eletrodoméstico já estará usando Java. Já existem muitos produtos por aí assim.

Até o chip do celular GSM que vc. usa ou o seu cartão de ticket refeição pode estar usando Java, sem que vc. saiba disso.

A adoção em dispositivos discretos como eletrodométicos era um problema para a plataforma em 1995. Hoje, não é mais faz tempo...
Comentário de leonardo_lopes
Me mostre um teste onde: Me mostre um teste onde comprove a "qualidade" do java... Se você desejar eu envio vários onde mostra o alto consumo de memória e a perda de tempo do desenvolvedor para criar os aplicativos.

"Be realistic, ask for the impossible."
Leonardo Lopes Pereira
Comentário de leonardo_lopes
Existem algumas, mesmo: Existem algumas, mesmo assim. O gerenciamento automático de memória (simplificando os programas), o isolamento do ambiente externo (prevenindo que o programa dentro da VM prejudique o ambiente operacional de alguma forma, ou vice-versa), etc.
1) Gerenciamento automático de memória é possível mesmo sem uma máquina virtual.
2) Esse isolamento só existe na inexistência de bugs na VM, além disso ele consome mais recursos que o necessário e poderia ser substituido por um simples Sistema Operacional bem escrito.

A máquina virtual não atende apenas ao quesito portabilidade.
Verdade :)

Programas escritos em .NET (eca!) rodando sobre o Windows são tipicamente muito mais estáveis do que aplicações que rodam diretamente sobre o SO.
Isso é uma questão de qualidade de código e de implementações, não tem nada a ver com a plataforma.

"Be realistic, ask for the impossible."
Leonardo Lopes Pereira
Comentário de Penetro
Java como SO??: Gostei do bom senso em suas respostas. Por isso gostaria de lhe fazer uma pergunta.

Creio que no futuro, o número de bits do processador, a quantidade de RAM e a frequência de clock vão se tornar conceitos com tanto sentido quanto tem hoje o mehor tipo de madeira para se fazer papiro. E eficiência vai ter a mesma importância que o seu nível de energia num FPS com a trapaça de "god" ativada. Nessa época, não fará a mínima diferença você estiver rodando uma máquina real ou virtual...

Mas de hoje até lá, o que você acha da idéia do Java se tornar um Sistema Operacional, como preconizam algumas publicações sobre o Java?

Vale a pena pagar o preço (não pense apenas em PCs, mas em geladeiras, fornos de micro-ondas, aparelhos de DVD, etc...)?


[]s
Penetro

Comentário de Dm7
Sim, inclusive meu celular: Sim, inclusive meu celular tem o Java. Na realidade, se esse código já estivesse aberto naquela época, acredito que eles teriam avançado mais rapidamente, apenas isso, e não apenas nesse campo.
Comentário de hamacker
Bem corrigido, as vezes eu troco os nomes dessas fundacoes: Bem corrigido, as vezes eu troco os nomes dessas fundacoes, acho que é porque ambas sao voltadas para web.

É interessante como as tecnologias se alternam, o pessoal fala sobre o beneficio das VMs e eu me lembro da época das linguagens (semi)interpretadas que necessitavam de runtime para executar seus aplicativos. Folcloricamente chamaram linguagens assim de arcaico, e a moda passou a ser linguagens 100% compiladas, alternou de novo, e estamos falando de maquinas virtuais como a 8a. maravilha do mundo. Nao estou me queixando, mas quando é que vai voltar o dbase ?
Comentário de Peter Parker
IBM: E alguém duvida que a IBM seria a primeira a fazer isso? Quem mexeu com o "jdk" da Microsoft lembra o pesadelo que foi aquilo.
Comentário de Patola
Então: Essas licenças, por melhores que sejam, não possuem as garantias necessárias para proteger uma plataforma de desenvolvimento (que não se compõe apenas de software ou código, mas de regras, especificações e padrões) e sua comunidade de ataques como esses

Exatamente; a licença da plataforma de desenvolvimento não muda, apenas de alguns softwares (JVM e bibliotecas), certo? Então qual o perigo para a plataforma que a liberação do código apresenta? Nenhum, oras. O mesmo perigo que uma implementação concorrente (Harmony) apresenta, não?
--
Dicionário rápido para o br-linux:
  • É exceção e não excessão.
  • É licença e não licensa.
  • É discussão e não discursão.
  • É opinar e não opnar.

Comentário de Copernico Vespucio
qual?: Me diz que tipo de teste vc. gostaria, só por curiosidade. Não prometo nada pq já estou envolvido em um.
Comentário de Copernico Vespucio
Java não é um SO: Mas de hoje até lá, o que você acha da idéia do Java se tornar um Sistema Operacional

Tenho discutido já infinitamente esse assunto com o Nêmesis... :/

Java não é, nunca foi, nunca será e nem pretende ser um Sistema Operacional. A máquina virtual java, no caso do seu PC por exemplo, é (apenas) uma camada controlada de abstração sobre as rotinas de sistema.

Isso significa que, se um programa em Java executa I/O, quem realmente realiza a operação é o Kernel do SO.

Existem sim, mas de um projeto de Sistema Operacional escrito em Java (assim como existem SO escritos em C, Assembly, Lisp, etc.), como o JNode (www.jnode.org). Mas um runtime java não tem a implementação necessária para substituir um SO. Java não é um SO, mas o JNode, que por acaso é escrito em Java, é um.

Um contra-argumento possível seria que existem dispositivos em embarcados que rodam diretamente sobre o java, sem SO "por baixo". Pois bem, qualquer dispositivo desse tipo tem rotinas acessíveis diretamente pelo hardware, através de uma interface (senão, seus programas não poderiam utilizá-lo). Para realizar suas tarefas, a JVM acessa diretamente essas rotinas nesses processadores.

Instalar Java em um dispositivo que nunca teve (ou precisou de) um SO não faz com que ele precise de um.

Concluindo, sua preocupação com alguma forma de retrabalho (java é algo que substitui o meu sistema operacional) não é necessária, portanto.

como preconizam algumas publicações sobre o Java

Esses artigos (já li alguns e ri um pouco) são escritos por gente inteligente, capacitada e idônea...

...Que jamais se deram ao trabalho ou tiveram a intenção de conhecer a plataforma Java! Se te interessam informações sobre Java, procure artigos em fontes especializadas:

http://java.sun.com

(na falta de algum interessante em evidência, e com tempo sobrando, leia a própria especificação de JVM em http://java.sun.com/docs/books/vmspec/2nd-edition/jvms-java5.html para entender com detalhes como tudo funciona).

http://www.javalobby.org/

http://www.javafree.org/javabb/forum.jbb (o pessoal lá é gente boa e se vc. postar suas dúvidas vão ter o maior prazer em explicar).

Então, geladeiras, fornos, microondas, DVDs. etc. usando Java continuam controlados pelos próprios chips ou SOs. Java é apenas uma camada (controlada) de abstração que permitem aos aplicativos o acesso a esses recursos a partir de uma mesma interface.
Comentário de Copernico Vespucio
+1 correção: Bem corrigido, as vezes eu troco os nomes dessas fundacoes, acho que é porque ambas sao voltadas para web

Deve ter trocado de novo, a Apache Software Foundation não é voltada para Web. Ela por acaso se tornou conhecida por um produto seu extremamente popular (o Apache Web Server). Mas ela é dividida em inúmeros projetos (para inúmeras plataformas e linguagens) e tem um projeto "guarda-chuva" chamado Jakarta responsável pelo desenvolvimento em Java. A ASF (e mesmo o Jakarta) não é voltada para a Web (como a mozilla foundation), ela é voltada para "tudo".

e eu me lembro da época das linguagens (semi)interpretadas que necessitavam de runtime para executar seus aplicativos

Acho que as linguagens as quais vc. está se referindo não são controladas por VMs, e sim por simples interpretadores...

Mas o conceito de VM é mais antigo sim, bem mais antigo do que Java.

O que ocorre é que as linguagens e plataformas vêem e vão, mas as técnicas e computacionais, protocolos etc. continuam valendo e vão bem, obrigado.

Isso siginifica que dificilmente o dbase vai voltar, mas técnicas e idéias utilizadas nele (as boas, espera-se) podem sim, serem aplicadas em produtos atuais ou no futuro.

Java não acrescenta nenhuma técnica computacional nova. Ela é apenas um conjunto de boas técnicas e práticas (assim como também boas restrições) colocadas juntas pela primeira vez.

Comentário de nemesis
algo a ver...: ...com uma linguagem incrivelmente limitante, uma VM pesadona e memory-hungry e camadas e mais camadas de frameworks, bibliotecas e o kcta4 para tentar compensar as limitações da linguagem em si...

é incrível como a comunidade java precisou criar dezenas de camadas de frameworks web apenas para tornar a criação de websites tão mais difícil que com python ou ruby... a impressão que tenho de java é de uma tecnologia francamente acadêmica e fora da realidade...

ou talvez seja exatamente o contrário: a ultra-complexidade e completo desacoplamento de tudo em java faz bonito entre gerentes de software em "enterprises" da vida, aquela galera que acha que bons tempos era COBOL...

complexidade por complexidade, fico com Brainfuck, que apesar de igualmente inútil, ao menos é divertido...

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

Comentário de nemesis
a M$ já tem seu java e se: a M$ já tem seu java e se chama .net. Além disso, me lembro de algum tempo atrás quando ela pagou aquela litigação pra Sun pelos anos de abuso com sua VM, que as duas empresas tinham se comprometido a algum tipo de interoperabilidade entre suas VMs. Até agora, só o ikvm do mono pode afirmar algo do tipo...

Engraçado, tenho bastante certeza de que Python é compatível com a GPL. E, no entanto, não vejo nenhum fork significativo, apenas ports para outras plataformas... se a IBM fizer fork e impor seus padrões, pode dizer adeus a clientes rodando código java genérico...

acho que ninguém quer perder clientes dessa plataforma tão lucrativa e complexa...

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

Comentário de nemesis
hehehe: "comunidade muito grande e motivada"

pensei que fosse piada! :))

mas vc está certo: realmente existem malucos com grande motivação para programação java! :P

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

Comentário de nemesis
e lá vamos nós: "é (apenas) uma camada controlada de abstração sobre as rotinas de sistema."

um kernel é uma camada controlada de abstração sobre as rotinas de sistema também. Embora as camadas subjacentes sejam diferentes, o papel é o mesmo.

"se um programa em Java executa I/O, quem realmente realiza a operação é o Kernel do SO."

só pq a camada subjacente atual com a qual ele se comunica é o kernel, não o hardware. Com chips falando em bytecodes java, a JVM poderia fazer requisições diretamente ao hardware ao invés de a um kernel nativo: ela seria o próprio kernel!

"Mas um runtime java não tem a implementação necessária para substituir um SO."

...ainda! Mas todos os aplicativos java dependem da API de alto nível de IO e outras. Uma vez que exista um chip java, as chamadas às rotinas do kernel podem ser implementadas diretamente como rotinas java para manipular o hardware, sem consequências para o código de aplicação java, que está usando as chamadas de alto nível da API...

A JVM faz o papel misto de chip de computador/SO, suas stdlibs são a API do sistema, mas hoje, um programa java é iniciado por um aplicativo nativo externo a esse esquema. Com beanshell ou similares + um chip que efetivamente rode bytecodes java, temos um SO completo... não adianta negar: java é um SO completo.

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

Comentário de Copernico Vespucio
concordo discordando:
1) Gerenciamento automático de memória é possível mesmo sem uma máquina virtual.

Isso lá é verdade. Vc. pode delegar suas rotinas de alocação a uma API e incorporar o gerente de memória em sua aplicação. Mas eu ainda acho uma VM mais poderosa para esse tipo de tarefa.

Esse isolamento só existe na inexistência de bugs na VM

Não exatamente o isolamento, mas os benefícos que ele traz. Concordo. Mas o runtime que gera a sua VM é um software com tempo de vida muito maior que cada aplicação que vc. faça em particular. Isso significa que é muito mais difícil a implementação de uma VM apresentar bugs do que sua própria aplicação.

Em suma: Uma aplicação nativa tem muito mais possibilidade de apresentar bugs de proteção ou de gerenciamento de memória do que uma feita para executar em VM.

ele consome mais recursos que o necessário e poderia ser substituido por um simples Sistema Operacional bem escrito.

Assim como Sistemas Gerenciadores de Bases de Dados enormes e pesados (Oracle, PostGres) poderiam ser substituídos por "simples" rotinas de manipulação de arquivos binários de forma específica para cada aplicação... :/

Analogias à parte, não há como um programador prever as condições de tempo de execução de um SO quando o seu programa estiver executando. Sistemas Operacionais não são, por definição, imprevisíveis. Ao usar uma VM vc. está trocando um ambiente hostil e imprevisivel do SO (ou do hardware) por um ambiente autocontrolado e previsível.

Isso é uma questão de qualidade de código e de implementações, não tem nada a ver com a plataforma.

Não acho, pq a VM .NET permite abstrair os acessos a APIs (não documentadas, pra variar...) do sistema, que é justamente o que costuma causar instabilidade.

Comentário de Copernico Vespucio
acho que não: Então qual o perigo para a plataforma que a liberação do código apresenta? Nenhum, oras. O mesmo perigo que uma implementação concorrente (Harmony) apresenta, não?

Acredito que uma implementação independente como o Harmony, e qualquer outra que possa aparecer, não representa perigo à plataforma enquanto houver uma implementação de referência que siga rigorosamente os padrões.

Isso pq se houver uma aplicação correta que não roda de jeito nenhum no Harmony, sempre pode-se dizer "Na implementação oficial funciona".

O meu problema não é com a abertura do código, simplesmente. A necessidade que vejo é garantir que ninguém possa "tomar posse" da implementação de referência sem ser obrigado a obedecer os atuais padrões e processos.

Então sou até a favor da abertura do código, desde que sob um licenciamento que garanta essas características. Toda JVM deve obedecer obrigatória e rigorosamente as especificações do JCP e ponto final.
Comentário de Copernico Vespucio
.NET != JavaM$: a M$ já tem seu java e se chama .net

Com uma CLR muitas vezes pior que o HotSpot (na verdade uma cópia chupada da JVM 1.1, que eles tinham acesso e, conforme a conclusão do litígio, não deveriam usar mais). Java, pela maturidade da plataforma, continua causando problemas para a M$, principalmente com essa característica "chata" de rodar sem problemas em Linux e MacOS tb.

A M$ adoraria pôr as mãos em código atualizado do Hotspot. Faz tempo que eles esperam por isso.

Engraçado, tenho bastante certeza de que Python é compatível com a GPL. E, no entanto, não vejo nenhum fork significativo, apenas ports para outras plataformas...

Python é uma linguagem, não uma plataforma. O que acontece é que novos interpretadores são construídos para novas plataformas. São questões diferentes.

se a IBM fizer fork e impor seus padrões, pode dizer adeus a clientes rodando código java genérico...

Embora a IBM tenha uma preocupação maior com a interoperabilidade e padrões abertos do que a M$, essa é uma verdade sim. Ela gosta de compatibilidade, desde que os outros é que tenham que se compatibilizar a seus produtos, não o contrário.
Comentário de Copernico Vespucio
Repetindo a mesma coisa: Caso alguém se interesse em assistir debates (meus, por exemplo) com o Nêmesis sobre a plataforma Java, basta fazer uma busca no site.

Não vou fazer isso aqui novamente (principalmente por ser off topic), pq a declaração dele não acrescenta nada de novo em relação ao que já foi respondido antes. Não sei quanto a vocês, mas eu tenho mais o que fazer.

Se vc. tiver alguma declaração ou dúvida realmente nova, Nemesis, eu respondo. Se não... RTFM.

[]s
Comentário de Copernico Vespucio
Será?: Será mesmo?
Ou isso teria comprometido a padronização da plataforma?

Hoje, talvez Java seja suficientemente maduro para se pensar em uma abertura. Mas tenho minhas dúvidas de que isso teria sido uma boa idéia em 1997.
Comentário de talexbh
"Fagocitose" do sun-java: liberação de código, por si só, é positivo. O complicado é o chacal que está a espreita para fazer o Java Clone - Episódio 2.

Eu **pessoalmente** não agrado muito do Java - minha praia é Python - a qual tb vem sofrendo uma da m$ chamada, pomposamente, de Iron(?)Python, e que permite acesso às bibliotecas da maledita .NET . Para mim eles querem é fazer o tal do Embrace, Extend and Exterminate com o Python.

Uma dúvida paira na minha cabeça: se meu produto é fechado e eu uso código livre nele - mas mantenho o produto fechado omitindo este "pequeno detalhe de nós dois", o que se pode fazer a respeito? Como se certificar - o tempo todo - de que a m$ não está se apropriando de código alheio indevidamente? Complicado, hein??


Comentário de Dm7
Esta é uma boa indagação.: Esta é uma boa indagação. Podemos usar o próprio Linux como comparação, ou outros softwares que já nasceram livres. Seria interessante manter o código fechado, até estar maduro o suficiente para ser liberado? Talvez para uma empresa possa ser interessante.
Comentário de Xisberto
Concordo com você: e acho que outras empresas deveriam fazer o mesmo.

?u vi ?atas liberan softvaron? Do uzu liberan lingvon!!!
Comentário de hamacker
Voce nao entendeu o que eu: Voce nao entendeu o que eu quiz dizer sobre JVM e as linguagens interpretadas, o que eu quero dizer é que o pessoal que usa JVM (pelo menos aqui nesta thread) o elogia exatamente pelos mesmos motivos duma linguagem (semi)interpretada : alocação dinamica de memoria, reutilizacao de codigo, segurança, cross-plataform, etc... Não ví ninguem lançando novidades, poderiam por exemplo ter citado o sandbox para impedir que crassos erros de programação invadam o SO hospedeiro, mas não, sempre as mesmas razoes pela qual se utiliza linguagens interpretadas desde o século passado (uau, tô parecendo um homem centenário agora), afinal o dbase que nao falavamos que era crossplataform mas rodava em DOS/MSX/CPM. :) Enfim, o ponto alto era o rodizio de tecnologias que revivem sobre outros nomes.

Comentário de Copernico Vespucio
poderiam por exemplo ter: poderiam por exemplo ter citado o sandbox para impedir que crassos erros de programação invadam o SO hospedeiro

Isso foi citado sim... Quando se falou de isolamento.

alocação dinamica de memoria

Alocação não, isso qquer linguagem faz. Vc. deve estar se referindo à gerência de memória, e isso uma plataforma não tem isso só pq usa um interpretador. Gerência automática de memória é uma característica que só existe em VM.

seguranca

Segurança pode ser característica de VM por consequência do isolamento. Mas não é uma caracteristica exclusiva de VM.

Particularmente, creio que Java tem uma política de segurança muito boa (pq foi criada com isso em mente), independente de ser baseada em VM.

afinal o dbase que nao falavamos que era crossplataform mas rodava em DOS/MSX/CPM. :)

Hehe. Na época era mais simples, não? :)) "Tempos qie não voltam mais..."

O DBase era portado para mais de um sistema (era fácil, pois existiam poucas diferenças estruturais entre o DOS e o CP/M), assim como existe implementação de vários interpretadores modernos para mais de uma plataforma.
Comentário de nemesis
mais características de SO: "Segurança pode ser característica de VM por consequência do isolamento."

gozado, eu poderia jurar que segurança e isolamento é exatamente o que tinham em mente quando criaram memória virtual e o conceito de espaços de endereçamento separados por processo.

e depois dizem que a VM java não é um SO... :P

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

Comentário de Hugo
Em outras palavras você é: Em outras palavras você é a favor de uma JVM aberta e não de uma JVM livre.
Não acho que uma JVM livre da sun iria fazer mal a linguagem, visto que a plataforma já esta bem estabelecida e quailquer possível fork não teria sucesso.

--
"Precisamos de mais gênios humildes no mundo, hoje somos poucos!"
JID: hugo@jabber.org
Comentário de Copernico Vespucio
JVM Livre: Se por "JVM Livre" se entende por licença GPL, tal como ela é hoje, sem acréscimos, sim: Sou a favor de uma JVM aberta e não-livre.

Mas um ponto deve ser considerado. Talvez a licença ideal não precise ser necessariamente incompatível com a GPL. Muitas licenças que acrescentam exigências adicionais - seja ao autor, seja ao "consumidor" - são consideradas "GPL compatible".

Tudo dependerá da interpretação das 4 liberdades do ponto de vista da comunidade (na verdade, infelizmente, vai depender do ponto de vista da FSF, que é quem diz o que é compatível ou não com SL).

O fato do autor, ou quem modifica o código preexistente não poder distribuir implementações parciais, não testadas ou incompatíveis com as especificações JCP representa uma ameaça às liberdades ofertadas para os usuários?

Então eu deixo a cargo dos detentores do código o direito de escolher a licença que melhor caber à situação (talvez a CDDL, como o Open Solaris?). Que eles liberem o produto à sua maneira.

Em seguida, deixo a cargo da FSF (ou da própria comunidade como um todo, o que seria o ideal) a tarefa de declarar se a JVM tal como foi oferecida é livre ou não.

Respondendo a sua pergunta, sou de opinião que a GPL não seria adequada para a questão (pelos motivos anteriormente citados). Ela falharia em proteger a plataforma de alguns dos "ataques" citados.
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