Quase Feito: Sun vai abrir o código do Java até o fim do ano

Site para discutir planos, progresso, notícias, opiniões, a escolha da licença, o modelo de governança, a marca Java, compatibilidade, ferramentas de controle, gerenciamento, compilação, etc.

:arrow: http://community.java.net/jdk/opensource/

Será que realmente fazer isso é uma boa idéia? :?

Primeiro eu achava que não, que os problemas de ser aberto poderiam acabar com o Java.

Mas depois, vendo a resistencia ao Java se comparado com plataformas abertas como o Python, ruby e mono, acho uma boa idéia quebrar essa barreira e abrir o Java.

Olá

Ainda há gente discutindo qual o melhor modelo para o licenciamento como é caso do Geir em http://blogs.codehaus.org/people/geir/

Mas é inegável que as mudanças já estão em curso.

O Java 6 tem uma versão nova a cada semana para avaliação da comunidade. Com este modelo muito mais gente o terá testado até o lançamento previsto para outubro.

O glassfish, que vale a pena experimentar e que na verdade é o Sun Application Server 9, tem todo seu código fonte aberto que pode ser baixado do CVS (a versão que baixei para estudar o grizzly tem 444Mb, 47726 arquivos em 12793 diretórios)

Outra mudança é que agora se pode usar o logo Duke desde que sem modificações. Vejam como em http://logos.sun.com/logosite.jsp?Category=third&Logo=duke-button
e http://logos.sun.com/logosite.jsp?Category=third&Logo=duke-button

Este é a reação da Sun ainda que tardia. Para nós desenvolvedores estes passos nos dão mais garantia de que o Java permanecerá vivo mesmo que a Sun eventualmente enfrente dificuldades.

[]s
Luca

Aí deixa de ser Java. Para alguma coisa entrar no Java tem que passar pela JCP e para que alguma modificação possa ser chamada de Java tem que passar por teste de compatibilidade.

Se alguém quiser fazer qualquer mudança, que fique a vontade. Mas não terá o direito de chamar o resultado de Java. A marca Java ainda vai ser propriedade da Sun Microsystems, não é por que ela abriu o código que qualquer vai poder sair usando como quiser.

Isso acho que seja bem provavel que aconteça, empresas como BEA, IBM, que já tem até suas VMs, com certeza lançaram versões “customizadas” com recursos que eles achem interessantes pros clientes dele.
Ai pode acontecer de vc ter o recurso X, na versão da IBM apenas, o Y na versão da BEA, e o W apenas na versão “oficial” da Sun.

Mas concerteza, a abertura do código vai ajudar muito o Java, como já acontece com grandes projetos abertos como os da Apache, o Jboss, kernel Linux, BSD (leia-se Apple Darwin com mais frescuras) e por ai vai.

ZehOliveira:

Aí deixa de ser Java. Para alguma coisa entrar no Java tem que passar pela JCP e para que alguma modificação possa ser chamada de Java tem que passar por teste de compatibilidade.

Se alguém quiser fazer qualquer mudança, que fique a vontade. Mas não terá o direito de chamar o resultado de Java. A marca Java ainda vai ser propriedade da Sun Microsystems, não é por que ela abriu o código que qualquer vai poder sair usando como quiser.

pois é, abriram o código funcional, mas na realidade continua a mesma coisa. Pode escrever: não dou 1 ano para aparecerem várias jvms com funcionalidades interessantes espalhadas por aí, e não estou dizendo que isso vai ser bom.

Muita gente cita o fato de não poder ser chamado “Java” como prova contra fragmentação, mas e daí? Dá só uma olhada nos projetos opensource. Alguém pegará o código, mudará o nome para algo como LNJ, “LNJ is not Java”, e fará a seguinte propaganda:

• Java “otimizado” para Gnome, é 100% compatível com o Sun Java e tem mais, fornece bindings GTK, etc, etc.

É esse “plus” que mata. Depois de pouco tempo uma ou outra se populariza porque alguns desenvolvedores não estarão muito interessados em esperar o JCP se decidir. Aí o Java ficará tão multiplataforma quanto o C++.

Eu não vejo isso como um problema, Thiago. Vai usar hack quem quiser, quem quiser construir software multiplataforma que use a ferramenta adequada.

Só vai usar um “Java Otimizado para GNOME” quem for usar Gnome. Se o cara quer construir um software usando essa ferramente, deve ter em mente que não vai funcionar no Windows. Se ele não consegue enxergar isso, aí é problema dele!

até pior, pode existir um programa feito em “java” que só rode em determinada jvm. Confio mais no apache tomando conta do java do que JCP

Não vejo isso com bons olhos… Pode ser um desastre! Não vou citar exemplos pois já falaram bastante…

A Paz!!

Vejo, muita resistência, por parte da comunidade Java em relação a isso, mas o próprio jJva teve que romper paradigmas para chegar onde chegou, e acretido que a quebra de mais este paradigma vai impulsionar o java a novas fronteiras.

Olhar negativamente não ajuda ninguem. Para quem esteve com o java desde o ínicio sabe as dificuldades encontradas, para mostrar que esta seria a melhor plataforma de desenvolvimento para uma Empresa, e essa mesma dificuldade será vivida agora, mas acredito que esta é uma mudança para melhor.

Só criticar o software livre, não vai levar a nada. Aceitar e aprender com a mudança é a melhor forma de evoluir. Além de que se não está satisfeito com a mudança, vá para outro plataforma de programação. Se acha que vai ser tão ruim assim, pare de programar em java imediatamente.

Eu vou continuar com o Java enquanto ele atender as minhas necessidades, caso contrário mudo.

E que está mudando para melhor é o Java. Por hora, vou continuar com ele.

Medo de aprender é medo de viver.

ZehOliveira:

Eu não vejo isso como um problema, Thiago. Vai usar hack quem quiser, quem quiser construir software multiplataforma que use a ferramenta adequada.

Só vai usar um “Java Otimizado para GNOME” quem for usar Gnome. Se o cara quer construir um software usando essa ferramente, deve ter em mente que não vai funcionar no Windows. Se ele não consegue enxergar isso, aí é problema dele!

Mas se hipoteticamente aparecer algo muito bom em determinada jvm, pode ser que haja um split não muito legal.

Olá

Porque você estão discutindo hipóteses?

E porque acham que só porque é Open Source devem aparecer vários sabores? Se fosse assim haveriam JBoss-Fedora e JBoss-Suse. Acho que a comparação com o linux não foi correta porque o Linux não é uma coisa só. É um amontoado de pacotes e aí sim, cada um empacota como quer. Mas o kernel do linux no Ubuntu é igual ao do Slackware ou do Gentoo.

A grande vantagem do Java virar Open Source é a de algum maluco resolver colocar coisas que até hoje a Sun não achou importante como uma javax.comm apropriada. De minha parte gostaria de ver uma maior integração com Flex para partir para web 2.1 sem as gambiarras do Ajax. Sendo Open Source a Adobe pode se interessar em fazer e também colocar como Open Source.

[]s
Luca

Pq hipótese se já temos isso com esse “turbilhão” de frameworks que aparecem todos os dias?

Luca:

E porque acham que só porque é Open Source devem aparecer vários sabores? Se fosse assim haveriam JBoss-Fedora e JBoss-Suse.

É mas, diga-se de passagem, o interesse em alterar a JVM é muito maior que alterar um JBoss da vida…

Luca:

A grande vantagem do Java virar Open Source é a de algum maluco resolver colocar coisas que até hoje a Sun não achou importante como uma javax.comm apropriada.

Passando pelo JCP, tudo bem, senão vai virar a “zona” que estamos falando.

Bom, vamos esperar para ver, já que vai ser feito mesmo.

A Paz!!

Olá

Pera aí, o assunto é o Java e não os programas que são feitos com Java que existem aos milhões. Um framework é um programa como outro qualquer feito com servlets, apenas é iniciado por um servidor de aplicações.

[]s
Luca

Luca:

Olá

Pera aí, o assunto é o Java e não os programas que são feitos com Java que existem aos milhões. Um framework é um programa como outro qualquer feito com servlets, apenas é iniciado por um servidor de aplicações.

[]s
Luca

Eu sei… Só quiz dar um exemplo real do que pode acontecer com o Java.

A Paz!!

Olá

paulohbmetal:

É mas, diga-se de passagem, o interesse em alterar a JVM é muito maior que alterar um JBoss da vida…

Acho que sei de muito mais servidores de aplicação do que JVMs. Hoje mesmo coloquei aqui um comparativo só com os 7 principais Open Source. Se incluir os pagos então a coisa vai longe. Veja:
http://www.guj.com.br/posts/list/39289.java

[]s
Luca

É mais aqui pode-se encontrar uma lista considerável de JVM’s também.

A Paz!!

Olá

Haver muitas JVMs nunca foi problema. Tanto que da lista que mostrou há algumas desativadas há mais de 5 anos e outras que nunca se tornaram conhecidas.

Continuo insistindo: a discussão aqui é sobre Java Open Source. Se o projeto Harmony já estivese funcionando você teria algum exemplo para mostrar.

[]s
Luca

Luca:

Continuo insistindo: a discussão aqui é sobre Java Open Source. .

Isso mesmo, não sei se notou mas, na lista que passei, as Open Source são a maioria e com a abertura do fonte a tendência é triplicar/quadruplicar sei lá, vai aumentar (e muito), e com o aumento vem as incompatibilidades… Daí pode ser um abraço para o “Write once, run anywhere”… Deus queira que não.

Mas, como disse vamos esperar pra ver.

A Paz!!

Não vejo isso com bons olhos… Pode ser um desastre! Não vou citar exemplos pois já falaram bastante…

Concordo!!!..

Sendo bom ou nao a abertura, acho que a Sun deveria se manifestar apenas quando tivesse alguma coisa concreta pra mostrar. Na proxima semana vem um executivo e desmente essa noticia. Dai daqui um mes eles voltam a carga dizendo que “estao quase la”. A Sun ta perdendo a credibilidade.

Marcio Kuchma

Olá,

Vejo tanto um medo desmedido dos ditos “forks”, quanto uma confiança exagerada na gestão deste “processo”. Sou jovem e relativamente inexperiente em Java (22 anos, 4 desenvolvendo em J2SE e J2EE), mas creio que seja a primeira vez que uma linguagem enfrente um desafio semelhante. Se alguma outra linguagem já passou por isso, certamente não foi em contexto semelhante ao que vivemos agora.

Não tenho medo dos forks; Se alguém desenvolver para a suposta “Gnome JVM”, estará abrindo mão da portabilidade, conscientemente. Uma linguagem não pode - ou melhor, não deve - se comprometer em resolver o problema da “irresponsabilidade” do desenvolvedor. Em outras palavras: é melhor manter o código fechado, para “garantir” a portabilidade tal qual ela existe hoje, ou os benefícios da abertura do código são maiores? Creio que nem é preciso responder.

Por outro lado, se a entidade mantenedora da especificação não funcionar de forma eficiente, e com a “velocidade” necessária, aí sim, concordo que a linguagem será refém de um movimento como o descrito. É preciso que a governança adotada seja livre de interesses egoístas, e realmente zele pelo aprimoramento constante da linguagem.

Resumindo minha opinião: como esse problema é, sob certos aspectos, “original”, é preciso que seja administrado como tal. Serão necessários respeito, confiabilidade e eficiência por parte da entidade mantenedora da especificação; e apoio, ética e responsabilidade por parte dos desenvolvedores colaboradores.

Rodrigo

E como fica o papel do JCP com o Java Open ? Pq na minha opinião, não me importa quem implementou, desde que seja aprovada e passar no teste de compatibilidade, estando aderente à especificação.

Talvez o maior problema vai ser especificação x time-to-marketing para tecnologias emergentes.

Se a integração com rich media, como citado (flex no caso) tiver uma JSR e a adobe implementou, a JVM dela terá que passar no teste de compatibilidade, passou pronto … ok, virou uma JSR válida.

Agora várias JSR saindo ao mesmo tempo, e o teste de compatibilidade determinar quais devem fazer parte obrigatoriamente da implementação, esse vai ser o problema que enxergo, organizar a bagunça !

Bom lembrar que o sempre comaprado Linux só teve o LSB muito depois dos forks, Java livre já nasce padronizado e com TCK.

exatamente…
eu ainda nao vi desvantagens em java ser open source…

de maneira geral, se alguem quisesse “copiar” o source do java, ele esta disponivel ha algum tempo (mesmo da jvm)

Partes do JDK já são open source, como todo pacote java.util.concurrent. Quantos forks dele existem?

Vão ser criados inúmeros forks da JVM da Sun, tenho certeza disso. Só que quantos vão chegar ao ponto de valer a pena serem usando em um projeto sério?

Baixem os fontes do JDK, que estão disponíveis sob a licensa JRL. Sério baixem os fontes. Só compilar o trem já é um parto. São milhões de linhas de código então entender e extender vai ser uma tarefa extremamente cara. Não vai ser simplesmente um projeto Open Source que vai conseguir isso, vai ter que existir uma empresa investindo pesado por traz.

Perfeito. Estes tempos parei pra ver como funcionava o codigo da API NIO e ja foi um parto imagina fazer isso pra toda JVM.

]['s

soh para esclarecer:
qualquer um pode fazer um fork, mas soh pode chamar de java ou falar que eh compativel com java se passar no TCK…
entao um possivel LNJ nao seria diferente de qq nova linguagem, no sentido de que a sua aplicacao escrita em java ainda vai precisar de uma jvm que passe no tck…