A partir da próxima versão do Java, prometida para o mes que vem, a implementação de referência passará a ser o OpenJDK no lugar da JDK padrão. Essa era uma promessa antiga da Sun ainda, mas que não tinha sido cumprida provavelmente por questão de patentes.
[quote=marcosalex]A partir da próxima versão do Java, prometida pro mes que vem, a implementação de referência passará a ser o OpenJDK no lugar da JDK padrão. Essa era uma promessa antiga da Sun ainda, mas que não tinha sido cumprida provavelmente por questão de patentes.
http://blogs.oracle.com/java/entry/moving_to_openjdk_as_the[/quote]
Notícia muito boa. O Openjdk não anda muito legal não. Em questão de desempenho ele está no mínimo umas 5x atraz da oracle vm.
Bacana …vai reduzir o receio de alguns …
Legal. Muito boa notícia. 
Uma notícia realmente sensacional 
[quote=juliocbq][quote=marcosalex]A partir da próxima versão do Java, prometida pro mes que vem, a implementação de referência passará a ser o OpenJDK no lugar da JDK padrão. Essa era uma promessa antiga da Sun ainda, mas que não tinha sido cumprida provavelmente por questão de patentes.
http://blogs.oracle.com/java/entry/moving_to_openjdk_as_the[/quote]
Notícia muito boa. O Openjdk não anda muito legal não. Em questão de desempenho ele está no mínimo umas 5x atraz da oracle vm. [/quote]]
eu sempre digo isso, mais sempre dizem que a diferença de desempenho é psicológica >.<
existem também alguns problemas com swing, não sei especificar. mais o jdownloader por exemplo quando executado em openjdk fica com os menus estranhos.
Muito bom! A OpenJVM vai ganhar uma credibilidade enorme com isso.
Mas me tirem algumas dúvidas:
A Oracle…
… pode desenvolver uma Reference Implementation (RI) da sua própria tecnologia? Se sim, ela acabou de passar o seu trabalho para a comunidade fazer.
… vai continuar regendo o TCK e isso não é uma forma de controlar (limitar) a OpenJVM? A comunidade pode adicionar itens extras nessa RI?
Claro, sempre pôde. A direrença era que a RI apesar de gratuita, não era 100% livre, por uma série de motivos.
Não, porque ela trabalha no OpenJDK também, assim como a Sun também sempre trabalhou.
Sim, essa é a briga eterna. Muitos desenvolvedores não fazem JVMs alternativas porque não concordam com a forma de certificação delas, por causa do tck. A grande polêmica é porque a Oracle antes de adquirir a Sun também era contra o tck, agora que está do outro lado, não se pronunciou. Ela nunca disse que não iria mudar, mas também nunca disse que vai deixar do jeito que está.
Sempre pôde, mas resta saber como a Oracle vai tratar essas contribuições sobre a implementação.
:arrow: será que, à partir de agora, questões como segurança, desempenho etc serão resolvidas mais rapidamente?
:arrow: alguém sabe dizer se o open jdk será referência para o java ee 7?
[quote=pcassiano]
:arrow: alguém sabe dizer se o open jdk será referência para o java ee 7?[/quote]
Provavelmente.
Mas lembrando também que a Oracle provavelmente vai manter a vesão jRockit comercial, que talvez vire uma JVM Enterprise, com código proprietário e patentes. Daí não sei até que pondo ela vai melhorar a qualidade do OpenJDK, embora ela venha lançando melhorias pra ele, inclusive vindas do jRockit.
[quote=marcosalex][quote=pcassiano]
:arrow: alguém sabe dizer se o open jdk será referência para o java ee 7?[/quote]
Provavelmente.
Mas lembrando também que a Oracle provavelmente vai manter a vesão jRockit comercial, que talvez vire uma JVM Enterprise, com código proprietário e patentes. Daí não sei até que pondo ela vai melhorar a qualidade do OpenJDK, embora ela venha lançando melhorias pra ele, inclusive vindas do jRockit.[/quote]
Eu usei a jrockit e achei inviável para todo tipo de projeto que se pode imaginar. É simplesmente uma jvm que aloca ela mesma(completamente) na memória ram. Um netbeans rodando nela ocupa mais de 1Gb de memória.
A jvm convencional resolve de maneira muito mais equilibrada a grande maioria dos problemas. Esse produto na minha opinião é para inglês ver.
Por falar nisso quem mais daqui do forum fez experiência com a JRockit?
Me tirem uma dúvida:
Quer dizer que não vai existir Java 7 (com este nome) agora o nome vai ser OpenJDK?
[quote=juliocbq]
Eu usei a jrockit e achei inviável para todo tipo de projeto que se pode imaginar. É simplesmente uma jvm que aloca ela mesma(completamente) na memória ram. Um netbeans rodando nela ocupa mais de 1Gb de memória.
A jvm convencional resolve de maneira muito mais equilibrada a grande maioria dos problemas. Esse produto na minha opinião é para inglês ver.
Por falar nisso quem mais daqui do forum fez experiência com a JRockit?[/quote]
O jRockit não é pra rodar em sistemas standalone, é pra rodar em servidores. Eu mesmo nunca fiz testes, mas aqui no GUJ tem muita gente que postava ganhas consideráveis em desempenho com ele, principalmente se haviam várias conexões concorrentes, fora as ferramentas de monitoramento e gerenciamento da JVM que eram bem mais completas.
Mas nunca testei ele, no máximo fiz testes semelhante ao seu, usando na máquina pra desenvolvimento.
[quote=marcosalex][quote=juliocbq]
Eu usei a jrockit e achei inviável para todo tipo de projeto que se pode imaginar. É simplesmente uma jvm que aloca ela mesma(completamente) na memória ram. Um netbeans rodando nela ocupa mais de 1Gb de memória.
A jvm convencional resolve de maneira muito mais equilibrada a grande maioria dos problemas. Esse produto na minha opinião é para inglês ver.
Por falar nisso quem mais daqui do forum fez experiência com a JRockit?[/quote]
O jRockit não é pra rodar em sistemas standalone, é pra rodar em servidores. Eu mesmo nunca fiz testes, mas aqui no GUJ tem muita gente que postava ganhas consideráveis em desempenho com ele, principalmente se haviam várias conexões concorrentes, fora as ferramentas de monitoramento e gerenciamento da JVM que eram bem mais completas.
Mas nunca testei ele, no máximo fiz testes semelhante ao seu, usando na máquina pra desenvolvimento.[/quote]
Pois é, isso eu imaginei mesmo. Tem que ser servidor muito robusto. Mas em termo de processamento sinceramente não existe ganho. Existe a redução do gargalo do coletor de lixo porque tudo já está alocado em memória(o que descarta praticamente a necessidade de um gc para gerenciar tempo de vida de objetos). Pra desktop não serve como solução.
Claro que faz sentido colocar o OpenJDK como RI, assim a Oracle renomeia Hotspot para JRockit e vende como a lendaria VM mais rapida.
Gostaria muito de ver um Bench de JRuby rodando sobre a atual JRockit para saber o quanto melhor ela é quando comparada com a Hotspot.
Tendo a renomeação o povo vai crer que openjdk = hotspot e jrockit sempre paga e mais rapida.
[quote=juliocbq][quote=marcosalex][quote=juliocbq]
Eu usei a jrockit e achei inviável para todo tipo de projeto que se pode imaginar. É simplesmente uma jvm que aloca ela mesma(completamente) na memória ram. Um netbeans rodando nela ocupa mais de 1Gb de memória.
A jvm convencional resolve de maneira muito mais equilibrada a grande maioria dos problemas. Esse produto na minha opinião é para inglês ver.
Por falar nisso quem mais daqui do forum fez experiência com a JRockit?[/quote]
O jRockit não é pra rodar em sistemas standalone, é pra rodar em servidores. Eu mesmo nunca fiz testes, mas aqui no GUJ tem muita gente que postava ganhas consideráveis em desempenho com ele, principalmente se haviam várias conexões concorrentes, fora as ferramentas de monitoramento e gerenciamento da JVM que eram bem mais completas.
Mas nunca testei ele, no máximo fiz testes semelhante ao seu, usando na máquina pra desenvolvimento.[/quote]
Pois é, isso eu imaginei mesmo. Tem que ser servidor muito robusto. Mas em termo de processamento sinceramente não existe ganho. Existe a redução do gargalo do coletor de lixo porque tudo já está alocado em memória(o que descarta praticamente a necessidade de um gc para gerenciar tempo de vida de objetos). Pra desktop não serve como solução.[/quote]
O que torna a logica de uma aplicação standalone diferente de uma enterprise ? não vejo como diferenciar isso em nivel de negocio.
[quote=benflodin][quote=juliocbq]
Pois é, isso eu imaginei mesmo. Tem que ser servidor muito robusto. Mas em termo de processamento sinceramente não existe ganho. Existe a redução do gargalo do coletor de lixo porque tudo já está alocado em memória(o que descarta praticamente a necessidade de um gc para gerenciar tempo de vida de objetos). Pra desktop não serve como solução.[/quote]
O que torna a logica de uma aplicação standalone diferente de uma enterprise ? não vejo como diferenciar isso em nivel de negocio.[/quote]
Mas não é em nível de negócio, é na JVM. Não conheço o jRockit a fundo, mas um exemplo seria um algoritmo mais eficiente pra gerenciar concorrência ou um melhor escalonador de processos. Tem algumas implementações que são mais rápidas pra grandes volumes e mais lentas pra pequenas coisas. Por exemplo, um seria da ordem de n^8, outro seria de 2^n. Até uma certa quantidade de n, o segundo seria mais eficiente, mas a partir de um determinado valor, a diferença inverte.
Outro é em algoritmos de escalonamento, um pode prioriazar o primeiro processo, ou então o mais rápido ou o menor ou dividir igual por quantum de tempo, etc. Tudo isso pode influenciar em situações mais comuns no desktop ou outras mais comuns nos servidores.
Um outro exemplo, poderia ser no próprio just-in-time, que otimizaria o código utilizando melhor instruções próprias de servidores.
Só lembrando pra quem não sabe, o jRockit não foi criado pela Oracle, mas foi adquirido por ela, que continuou trabalhando na JVM.
No caso ela é inviável para o mundo das aplicações de prateleira. Se você colocar o jdownloader para rodar na rockit, vai ver que ele vai consumir uns 250% (ou mais) memória. Pelo que eu entendi foi a maneira que eles encontraram para sanar o problema de latência do coletor de lixo. Aplicações para usuários comuns não podem consumir muita memória porque são utilizadas em larga escala( exemplo explorer: quantidade de instâncias executadas).
Para um servidor robusto acredito que seja uma ótima solução, já que a ferramenta rodou muito bem( netbeans e glassfish). Embora somente o netbeans alcançasse brincando 1.2 Gb de ram. Se eu tivesse executado o glassfish facilmente alcaçavam os 2Gb de ram da minha máquina.