IBM desafia Sun a se unir ao Java de Código Aberto

Fora as conseqüências óbvias de se ter um java livre, acho que ia ajudar bastante na integração com o GNU/Linux - por exemplo, desenvolver um Look-and-Feel integrado com KDE ou Gnome com a mesma qualidade do Look-and-Feel do Java para Windows. As implementações atuais são bastante ruins.

De qualquer jeito, isso é o que eu posso classificar de excelente "pré-notícia". Espero que isso acabe se consolidando mesmo e vire realidade.

bem se defato isso acontecer o java sera a linguagem mais usada no mundo com certeza e quem sabe assim ela seja otimizada e melhorada, pois hoje eu acho o java muito lerdo um exemplo disso é o openoffice que sua base é o java
e com certeza microsoft sofreria um grande impacto

Uso java no meu dia a dia e vejo como sua grande vantagem a padronização. Essas regras são feitas por uma comunidade mas a palavra final sempre é da Sun. Caso o Java venha a ter seu código aberto, na minha opinião, corre um sério risco de cada fornecedor padronizar de uma forma e java perder sua força. Pode acontecer de ter vários "braços" (como ocorre com o Linux e suas diversas distribuições) e uma não ser totalmente compativel com a outra que seria horrivel.

André Penteado,

Não concordo. Temos milhares de projetos de código aberto e é difícil ver essa desordem que você citou. Todos nós sempre baixamos o Kernel do Linux do www.kernel.org, sabemos quem é o mantenedor oficial. Uma estrutura parecida aconteceria com o Java. É só a Sun ser a mantenedora oficial do Java. Outra coisa também é que não é falado que o Java seria GPL. Abrir o fonte é um passo, o Java ser GPL é outra totalmente diferente...

Mandark:

Java tem código-fonte disponível, as fontes vêm junto com o SDK. O que não se pode é alterá-las.

As possibilidades de um java software livre:

* Uso de código no gcj para fazer um compilador java para código nativo inteiramente compatível com as mais novas versões. Imaginem o gcj podendo compilar programas Swing compatíveis com Java 1.5! =)

* Inclusão do código em outras máquinas virtuais e JITs, como o Kaffe.

* Possibilidade de inclusão no java de um LookAndFeel nativo para Gnome e KDE, como o LookAndFeel de Windows (quem já programou com Swing sabe do que estou falando).

* Incentivo para os programadores enviarem patches (especialmente de segurança e bugs) para o java. Sim, com o código disponível no sdk do java existe essa possibilidade, mas não a motivação, pois o processo seria extremamente burocrático. A idéia é que com java open-source o processo se desburocratizaria por causa do item seguinte:

* Possibilidade do java evoluir no estilo "bazar" em vez do estilo Catedral! Basta respeitar as especificações e a evolução do java aumentaria em 10 sua velocidade com isso! É o que ocorre, por exemplo, com Python, que é bem padronizado.

A meu ver, JCP e outros processos continuariam existindo mas ninguém precisaria aprovar um JSR para um conserto de bug no java ou um patch contra exploit.

Lógico, existem muitas outras possibilidades que não pensei, talvez alguém pegue o java e faça uma versão dele com ponteiros "just for fun", ou façam um servidor CORBA com ele que rode no kernel do Linux. =P O legal do código livre é justamente você perder o controle e deixar as pessoas fazerem coisas antes impensáveis com seu código...

Do ponto de vista técnico as duas tecnologias são muito similares, com vantagem à Microsoft por hora (enquanto não sai o Tiger e o J2EE 1.4).

Reparem que muitos recursos incorporados ao Tiger já fazem parte do .NET. Não vai demorar para o Java se tornar ainda mais interessante.

Com certeza, abrir o código do Java e trabalhar num modelo mais open source é muito interessante, uma vez que a velocidade de evolução vai ser maior. Mas aí fica o risco: Nem sempre as empresas tem interesse em seguir no mesmo ritmo. Por outro lado, otimizações para as plataformas se tornarão instantaneas. Ao final da análise ainda resta a perguta: Se todos nós podemos participar do JCP, o que realmente mudaria?

Mandark, mas se o código for aberto e não seguir a licença GPL quem impediria a M$ (ou outra empresa) incorporar pedaços de código Java em seus produtos (dotNot por exemplo)?

"Ao final da análise ainda resta a perguta: Se todos nós podemos participar do JCP, o que realmente mudaria?"

Sim todos podem participar. Mas é a SUN que decide.E como o patola citou acima, existe uma burocracia grande para se fazer algo.

Acho que o grande medo da SUN é com isso enfraquecer sua posição como DONA do JAVA, e também existe a questão do nome.

JAVA agora é uma marca que a SUN utiliza em qq coisa.

Até um Java Desktop System criaram, uma distro Linux que só tem JAVA no nome.

Pois é LinuxNewsReader,

Até certo ponto o fato da SUN segurar tanto o Java é bom, de modo a garantir um controle sobre as mudanças que ocorrem. Por outro, engessa a tecnologia, um bom exemplo é o .NET, muita coisa que os usuarios da tecnologia Java pediam para a SUN e ela os ignorava foram incorporadas no .NET. Coinscidencia ou não, a versão 1.5 traz muitos destes recursos.

Meu grande medo é surgir variantes do Java, incompativeis entre si. Obviamente alguma será melhor que a outra, mas o excesso de opções só vai complicar. Deve haver um meio de controlar isso, mas ainda não consegui visualizar uma maneira razoável. Talvez a flexibilização do burocrático JCP seja a saída mais racional.

MediaSonic, por que essa enxurrada de versões diferentes e incompatíveis não aconteceu com Python? Ou com Perl? Ou com Ruby? Existe algo especial em Java que faz com que, se esta linguagem virar software livre, ela encontre um destino diferente das outras?

Patola,

Concordo plenamente com o que disse.

A verdade é que hoje não há muito espaço para tecnologias e plataformas proprietárias em nenhum campo onde a Microsoft entre e que consiga usar a sua posição monopolista do Windows para ganhar mercado. Tanto é que as únicas exceções (onde a M$ não está indo tão bem) são as áreas de consoles de videogame (onde a Sony domina) e a de PDAs e sistemas operacionais embedded, onde não há uma relação direta com o Windows. A únca saída para essas empresas é fornecer suas tecnologias e programas de forma livre (e usando uma licença no estilo GPL para evitar plágios) e ganhar em cima de serviços e programas proprietários complementares.

Se o Java continuar na situação de hoje vai ser engolido pelo .Net e ficará reduzido às plataformas não-Microsoft somente.

Java já tem algumas incompatibilidades entre as duas principais implementações de VM (IBM e Sun). São pequenas ao ponto de serem absolutamente desprezíveis.

Entre as versões de Java (1.1, 1.2, 1.4 e 1.5) existe incompatibilidade na 'biblioteca de classes padrão'.

Fazendo uma comparação com Python:

Python tem incompatibilidades entre suas implementações (CPython, Stackless Python, Jython, ...) que também são pequenas.

Entre as versões de Python (1.5, 2.0, 2.1, 2.2 e 2.3) existem incompatibilidades na biblioteca *e* incompatibilidades retroativas na linguagem, ou seja, se você usa uma característica da linguagem disponível no Python 2.2 provavelmente essa aplicação não funcionará no Python 1.5. Até certo ponto isso não deve ser considerado um contra se a gente pensar que o Java 1.5 vai ter construções que não existem em versões anteriores de Java.

Ou seja, essa 'ladainha' da Sun alegando que ela perderia o controle de Java e iriam surgir várias implementações incompatíveis é *balela* engana-trouxa.

Se surgirem VMs incompatíveis melhores do que a da Sun as regras da 'teoria da evolução do software' se aplicarão e os desenvolvedores certamente irão optar por usar uma VM melhor e automaticamente essa VM se torna o 'padrão'.

O que a Sun não quer é que a VM dela deixe de ser o padrão da indústria, e isso pra mim é quase equivalente a algumas práticas bizarras de criação de monopólios que empresas como a Microsoft usa.

Muda a forma mas não muda a função.

Patola, como não aconteceu? Só se vc não quiser ver. Veja bem, muitas empresas ainda usam a JVM versão 1.3.x e não a 1.4, apesar dos ganhos. Veja que o processo de aprovação do JCP é rígida e ainda assim propícia a incompatibilidades.

Agora a sua pergunta foi no minimo ridicula, seria o mesmo que perguntar:
O que o Java tem que as demais não tem para ser mais usada? Ah, por favor, seja mais coerente!

Se surgirem forks do Java, pior ainda. Observem que existe a possibilidade de perda do controle da situação. E cá entre nós, a SUN bem que gostaria de estar no lugar da MS em alguma outra vértice do mundo da informatica.

MediaSonic, estamos discutindo se o processo de abrir o código do Java propiciaria incompatibilidades e não se já aconteceu. Mas as diferenças entre as versões do Java - 1.2, 1.3, 1.4 etc. - são parte do crescimento incremental da linguagem e acho que ninguém espera que não seja assim. Se é pra comparar com coisas da Microsoft, uma empresa que controla todo o processo com mão de ferro, veja a quantidade de diferenças entre, por exemplo, ASP e ASP.Net. Tem alguma diferença fundamental de magnitude entre as já existentes entre Java 1.3 e 1.4? Na verdade acho que é ainda maior!

Minha pergunta ridícula é tão ridícula que você não respondeu - apesar da colocação do aCiDbAsE que ainda veio reforçá-la. Deixa eu relacionar os fatos pra ti, já que parece que você não faz sem ajuda: Existem pequenas diferenças entre as várias implementações de Python - CPython, Jython, Stackless Python, etc. - mas estas não são maiores que as já existentes entre o JDK da IBM e o JDK da Sun (ambos proprietários) para a mesma versão. Até aí ok? Você está me acompanhando?

Pois bem. A colocação que você fez que eu respondi foi essa: "Meu grande medo é surgir variantes do Java, incompativeis entre si.". Esse medo seria por java virar código livre.

Bom, a idéia então é comparar: já existem pequenas incompatibilidades nas implementações, equivalentes às existentes entre as de uma linguagem livre, o Python.

A pergunta ridícula que eu fiz se referiria a algo assim: POR QUE afinal de contas essas incompatibilidades aumentariam com o Java sendo código livre? O que nessa linguagem faria isso acontecer? Você não deixou claro por que acha que existe essa possibilidade e ainda, er, tachou minha pergunta de ridícula.

Aliás, pensando um pouco mais sobre o assunto, se a máquina virtual da Sun fosse liberada como código livre, pela possibilidade de reuso de código, acho que isso iria AUMENTAR a compatibilidade. Por exemplo? Imagine o gcj podendo utilizar código do java 1.5. Iria tornar-se uma máquina virtual bem mais compatível do que é hoje, e iria acompanhar bem mais de perto as modificações em Java. A mesma coisa pode ser dita do Kaffe e tantas outras aventuras livres no meio java.

Veja bem Patola, estas diferenças evolutivas são cuidadosamente controladas, vc sabe disso, isso tudo graças ao processo. Minha pergunta básica é: Sem este processo, não correriamos o risco de perdermos o controle? Simples assim. Volto a ratificar, talvez um afrouxamento do JCP faça com que tenhamos mais participações, talvez se a SUN fosse menos doutrinária, teríamos um processo muito similar ao S.L. mas sem perder o rumo em nenhuma hipótese. Nem sempre ser S.L. é a solução, não sabemos sequer o objetivo da SUN com o Java, é como já foi bem citado pelos colegas, hoje tudo da SUN gira em torno do nome Java, assim como na IBM gira em torno do Websphere (pelo menos os serviços transacionais, um belo carro da IBM).

Só não se esqueça meu caro, que as diferenças entre o Python e o Java são muito grandes, logo, a sua base de comparação não é muito sólida. Outra coisa, percebi que ficou um ofendido com as minhas colocações, peço desculpas, peço também para deixar de pensar que o S.L. é a solução para tudo. É só aparecer um com ideias diferentes que é taxado como um capitalista, adepto da MS, etc. Se fui agressivo contigo, é porque tudo que digo parece soar como uma ofensa, especialmente pra voce e isso me irrita, ver pessoas que só vêem por um ponto e se acham donas da verdade.

Voltando ao assunto, as poucas incompatibilidades que vierem a surgir *podem* ser incomodas a ponto de inviabilizarem o Java como uma plataforma de negócios, uma vez que existe uma exigencia muito grande nesta área. Não estou dizendo que isso virá a acontecer, digo que é mais propicio, não tendo um ponto de convergencia entre as ideias, alguem que bata o martelo.

Surge então uma última alternativa, que talvez viabilize o Java Open Source: Comprometimento com os padrões. Se as especificações do JCP forem seguidas de maneira rígida, as implementações jamais serão incompativeis entre si, sendo as interfaces respeitadas, não há o que discutir, mas no final das contas, se assim for, não teriamos muitas mudanças em relação ao modelo atual, que possibilitou o surgimento do Jikes e do Blackdown.

Ah, o GCJ não é um compilador nativo? De compilador nativo para uma máquina virtual o caminho é bem longo não é mesmo? Digo porque não sei até que ponto o reuso seria possivel, uma vez que enquanto uma máquina virtual funciona como um sistema operacional para o runtime, um compilador apenas adicionaria códigos para chamadas diretas e linkagem para bibliotecas de controle (memoria, system calls, etc).

Ah, o que fazem os defensores da Sun...

Para defender a Sun pode-se até mesmo dizer que software livre não é bom pra tudo, pode-se 'abrir uma excessão', pode-se 'dar uma trégua', pode-se até dizer que uma linguagem de programação não pode ser comparada com a outra porque são 'diferentes'...

Volto a relembrar dois estereótipos de programadores Java: o do Lemming e o dos programadores Java que apareceram no comercial 1984 do Apple Macintosh (http://www.pythonbrasil.com.br/moin.cgi/OsvaldoSantanaNeto?action=AttachFile&do=get&target=PythonRocks.zip)

São dois estereótipos, caricatos e não representam a totalidade dos programadores Java que conheço. Sei, por exemplo, que o Patola é um desenvolvedor Java que não se encaixa 100% nesse estereótipo. Mas participar de um Sun Tech Days oferece vários 'espécimes' de lemmings.

aCiDBaSe,

O Java é algo além de uma linguagem de programação, é uma plataforma de desenvolvimento que provê uma série de recursos que outras linguagens ainda não oferece, o Python não é exceção, portanto quando disse que Python e Java não eram bases solidas para comparação era neste sentido que quis explicitar.

Outra coisa, não estou defendendo a SUN, apenas quis levantar os riscos que podem vir a surgir.

Patola, não havia lido seu primeiro comentário, mas de acordo com ele, posso concluir que nossas idéias estão em sincronia, quando o assunto é flexibilizar a JCP, sem perder o foco da instituição. Logo a convergencia das idéias pode estar na orquestração do JCP pela SUN e o rigoroso respeito a ela por parte dos colaboradores que se disporem a implementar e melhorar um possivel Java Open Source.

PessoALL,
Nao se exaltem, por favor, nao confrontem seus egos, isto so faz com que nos afastemos de boas ideias, o soft livre é uma opcao viavel, mas todo amante do java ficara receoso, pois se o java (nao pense no java como uma linguagem de programacao, vai muito alem disto) eh o sucesso que eh hoje foi gracas tb a rigidez da sun e o controle no rumo que o java seguiu, mas nada impede que a abertura do codigo tb de bons frutos ao ambiente java, para mim o exemplo de um software livre perfeito eh o apache (estado da arte em um software).
Acredito que o ponto crucial seja financeiro para a sun (nao sou nenhum especialista nisto), isto eh apenas o meu ponto de visto. Acredito q a mudanca para o SL seja boa, mas que seja cautelosa para ninguem sair prejudicado nos seus interesses.

GCJ (+GIJ) é muita coisa: compila de .java pra .class, .java pra nativo, .class pra nativo e ainda tem uma máquina virtual pra executar os .class. Logo, sim, o gcj e o gij poderiam se beneficiar muito do código da JVM sendo liberado. E as bibliotecas java padrão em si também, pois a atual implementação livre delas está muito atrás da implementação da Sun...

Sera que ninguem encherga o que eu enchergo?
Facam o seguinte:
Testem o jikes. O compilador de java opensource
da IBM. Constatem. O jikes eh muito, muito melhor
que o compilador da sun.
A IBM tambem teu seu projeto de VM, soh que esta
bem mais atrasado queo jikes...
Quero ver o impulso que o linux vai ter quando
esse projeto maturar.