Sei que aqui não é lugar de postar notícias, mas o guj anda burocrático por demais.
Java 8 disponível como major release no site da oracle. Alguém já rodou?
Dentre as novas especificações da vm é que não existe mais permgen(graças a Deus)
http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html
Sem pergen não quer dizer que a memória não estoure do mesmo modo. [=
A memória vai estourar de qualquer modo não importe qual artifício se adote(em qualquer ambiente), se ela não for liberada(por isso se chama “memória”). Eu citei o novo modelo de memória do java 8(metaspace) para ver se começo uma discussão sobre isso.
Alguém notou alguma vantagem agora que as classes são alocadas na memória nativa?
na minha opinião não foi uma mudança tão impactante fora não possuir mais lixo de objetos de geração antiga.
Sim, mas o limite da permgen era irrisório - bem melhor ter que controlar um limite só. Será que a aproveitaram e aumentaram também o limite da memória padrão da VM? Adoraria parar de ter que colocar -XMX em qualquer aplicação ligeiramente mais pesada que faço. 
Sim, mas o limite da permgen era irrisório - bem melhor ter que controlar um limite só. Será que a aproveitaram e aumentaram também o limite da memória padrão da VM? Adoraria parar de ter que colocar -XMX em qualquer aplicação ligeiramente mais pesada que faço. :)[/quote]
Você não acha essa alocação e redimensionamento de memória automatizada perigosa? Num servidor pode comprometer todos os serviços que estão executando.
Pelo que andei lendo a se você errar no código o programa pode consumir o ambiente todo. A coleta de lixo só acontece se o uso do metaspace chegar a um limite em que não pode mais aumentar, por isso o “out of memory” é de extrema importância.
Para mim isso parece um retrocesso.
Detalhe, meu netbeans está comendo aproximadamente 1gb de ram com java 8.
Se eu quiser usar a minha máquina para trabalhar com ele terei de comprar bastante memória. Olha que nem o glassfish me atrevi a subir.
Não acho pois não é fácil sair alocando coisas no permgen.
É por essas e outras que não uso o Netbeans.
[quote=ViniGodoy]Não acho pois não é fácil sair alocando coisas no permgen.
É por essas e outras que não uso o Netbeans.[/quote]
Mas no java 7 o netbeans não expandia tanto. De qualquer forma, continuei testando aqui e aumentei a pressão da memória abrindo um aplicativo mais pesado para tentar simular um “out of memory” já que estou com meros 80mb livres e tive uma surpresa: “O metaspace recuou” para liberar espaço para a nova aplicação.
Muito inteligente. Se a jvm funcionar desse jeito redimensionando a todo instante os processos a coisa realmente ficou jóia. Mas será que pareia uma quantidade boa deles?
Bom, o fim da permgen foi um recurso muito comemorado e nas listas dos devs elogiaram bastante a abordagem atual, copiada do jrockit, antiga JVM da Oracle antes da fusão com a Sun.
Engraçado que aqui comigo o Netbeans sempre foi mais leve que o Eclipse depois de instalado suas dezenas de plugins pra atender. Sempre achei uma lenda dizerem que o Netbeans consome mais memória comparado com o Eclipse ‘pelado’.
De qualquer forma, que bom termos opção.
[quote=marcosalex]Bom, o fim da permgen foi um recurso muito comemorado e nas listas dos devs elogiaram bastante a abordagem atual, copiada do jrockit, antiga JVM da Oracle antes da fusão com a Sun.
Engraçado que aqui comigo o Netbeans sempre foi mais leve que o Eclipse depois de instalado suas dezenas de plugins pra atender. Sempre achei uma lenda dizerem que o Netbeans consome mais memória comparado com o Eclipse ‘pelado’.
De qualquer forma, que bom termos opção.[/quote]
Pois é. Aqui na minha máquina raramente ultrapassava a marca dos 400mb. Com o java 8 ele subiu até 1.12 gb mas no mac nenhuma applicação chegou a ser afetada e os procesos se organizaram repartindo os recursos entre si. No meu desktop de produção(linux mint kde 2gb, dual core, geforce 9400gt) apenas uma aplicação chegou a experimentar o out of memory( exemplo jfx modena bem pesado) e até chegou a lerdear.
Tá legal mas muita gente vai ter que se reciclar rápido, porque o paradigma mudou e vai quebrar muitos servidores por aí.
[quote=marcosalex]Bom, o fim da permgen foi um recurso muito comemorado e nas listas dos devs elogiaram bastante a abordagem atual, copiada do jrockit, antiga JVM da Oracle antes da fusão com a Sun.
Engraçado que aqui comigo o Netbeans sempre foi mais leve que o Eclipse depois de instalado suas dezenas de plugins pra atender. Sempre achei uma lenda dizerem que o Netbeans consome mais memória comparado com o Eclipse ‘pelado’.
De qualquer forma, que bom termos opção.[/quote]
Eu também não uso o Eclipse.
[quote=ViniGodoy][quote=marcosalex]Bom, o fim da permgen foi um recurso muito comemorado e nas listas dos devs elogiaram bastante a abordagem atual, copiada do jrockit, antiga JVM da Oracle antes da fusão com a Sun.
Engraçado que aqui comigo o Netbeans sempre foi mais leve que o Eclipse depois de instalado suas dezenas de plugins pra atender. Sempre achei uma lenda dizerem que o Netbeans consome mais memória comparado com o Eclipse ‘pelado’.
De qualquer forma, que bom termos opção.[/quote]
Eu também não uso o Eclipse.[/quote]
O melhor que existe em termos de ide na minha opinião e no qual uso em produção no trabalho é o intellij idea. Ele é prático, mas não acho que vai ter o comportamento diferente do eclipse ou netbeans rodando em cima do java 8.
É esse que eu uso. Gosto bastante, mas como toda aplicação Java, consome bastante recurso sim. De qualquer forma, as máquinas hoje tem recurso de sobra para agentar IDEs, então esse é o último fator que olho.
Voltando ao assunto Java 8, ainda acho que a linguagem está muito atrás da concorrência:
O recurso de Lambda saiu muito atrasado. Ele já existe há 2 anos em C++, e há muitos em C#.
Há poucas novidades em bibliotecas que permitam processamento assíncrono, uma das grandes vantagens de usar lambda. Nada comparado ainda ao async e await do C#.
Os “default methods” são uma piada comparados aos extension methods. Bem menos flexíveis, e bem menos interessantes.
Os recursos de Collections e Streams usando lambda são bem legais, mas ainda não se comparam ao LINQ (de onde foram copiados), nem em elegância da sintaxe, nem em poder de processamento, nem em flexibilidade.
Exceto pela API de Date/Time, não houve nenhuma API nova significativa. Ok, tivemos a adição de Streams e de comandos nas colections, mas vejo isso como uma consequencia natural do lambda - e um esforço pequeno, já que foi uma cópia descarada do C#.
Para uma versão que demorou tanto a sair, na minha opinião, ainda é bastante decepcionante - mesmo sendo ainda uma mudança mais significativa do que o Java 6 e 7.
É esse que eu uso. Gosto bastante, mas como toda aplicação Java, consome bastante recurso sim. De qualquer forma, as máquinas hoje tem recurso de sobra para agentar IDEs, então esse é o último fator que olho.
Voltando ao assunto Java 8, ainda acho que a linguagem está muito atrás da concorrência:
O recurso de Lambda saiu muito atrasado. Ele já existe há 2 anos em C++, e há muitos em C#.
Há poucas novidades em bibliotecas que permitam processamento assíncrono, uma das grandes vantagens de usar lambda. Nada comparado ainda ao async e await do C#.
Os “default methods” são uma piada comparados aos extension methods. Bem menos flexíveis, e bem menos interessantes.
Os recursos de Collections e Streams usando lambda são bem legais, mas ainda não se comparam ao LINQ (de onde foram copiados), nem em elegância da sintaxe, nem em poder de processamento, nem em flexibilidade.
Exceto pela API de Date/Time, não houve nenhuma API nova significativa. Ok, tivemos a adição de Streams e de comandos nas colections, mas vejo isso como uma consequencia natural do lambda - e um esforço pequeno, já que foi uma cópia descarada do C#.
Para uma versão que demorou tanto a sair, na minha opinião, ainda é bastante decepcionante - mesmo sendo ainda uma mudança mais significativa do que o Java 6 e 7. [/quote]
Ótima análise.
É esse que eu uso. Gosto bastante, mas como toda aplicação Java, consome bastante recurso sim. De qualquer forma, as máquinas hoje tem recurso de sobra para agentar IDEs, então esse é o último fator que olho.
Voltando ao assunto Java 8, ainda acho que a linguagem está muito atrás da concorrência:
O recurso de Lambda saiu muito atrasado. Ele já existe há 2 anos em C++, e há muitos em C#.
Há poucas novidades em bibliotecas que permitam processamento assíncrono, uma das grandes vantagens de usar lambda. Nada comparado ainda ao async e await do C#.
Os “default methods” são uma piada comparados aos extension methods. Bem menos flexíveis, e bem menos interessantes.
Os recursos de Collections e Streams usando lambda são bem legais, mas ainda não se comparam ao LINQ (de onde foram copiados), nem em elegância da sintaxe, nem em poder de processamento, nem em flexibilidade.
Exceto pela API de Date/Time, não houve nenhuma API nova significativa. Ok, tivemos a adição de Streams e de comandos nas colections, mas vejo isso como uma consequencia natural do lambda - e um esforço pequeno, já que foi uma cópia descarada do C#.
Para uma versão que demorou tanto a sair, na minha opinião, ainda é bastante decepcionante - mesmo sendo ainda uma mudança mais significativa do que o Java 6 e 7. [/quote]
É por isso que o javascript anda se popularizando e criando interpretadores do v8 autônomos(nodejs, qt quick). Java ainda tem a vantagem do ecossistema mas a sintaxe realmente é muito atrasada.
Netbeans também está acabando com a bateria da minha máquina. XD
Apesar dos pesares e dos já muito bem expostos tópicos explicados pelo Viny, eu comemoro bastante essa nova versão e os novos rumos da linguagem.
Hoje apesar de estar me focando no Groovy e no JS (ainda estudando o Node) é bom saber que a Oracle adotou uma postura mais agressiva de atualização da linguagem frente ao que era praticado no antigo JCP. No fim das contas, errando ou acertando, estão atualizando e melhorando. Erros ainda farão parte da jornada, o que é bom, afinal são com eles que aprendemos. Que corra atrás do prejuízo mesmo e que a linguagem só avance cada vez mais, afinal concorrência e boas opções sempre serão bem vindos.
No fim das contas, acho que até podemos proclamar “Voltem das colinas” afinal a Oracle pode até errar, mas com certeza está sendo porque está querendo acertar… Pelo menos pra mim (que nunca fui pras colinas) isso é um ponto BEM positivo.
Qaunto ao Java 8 está chegando tarde para o que deveria, mas acho que até cedo para o que poderia… E que venha o 9.
Abs [] 
Tambem comemoro as novidades, mesmo que atrasadas elas eram necessárias e o fato da evolução estar acelerando também é positivo, tanto as novidades já citadas quanto as outras.
Particularmente, espero que o Java tome um impulso com essas novas versões e que o Java 9 continue nesse ritmo.
Há um boato de que talvez o Java 9 remova a retro-compatibilidade para versões anteriores ao Java 5. Eu vejo isso de forma positiva, pois permitiria rever a implementação de background dos Generics e acabar com o erasure. Teríamos generics reais (como já existe em C#). Isso permitiria fazer coisas como:
T obj = new T();Outra discussão está em fazer o JNI 2.0, que permitiria integrar Java muito mais facilmente com código nativo. Na mesma linha dos métodos unsafe do C# - ou talvez com as facilidades do JNA.
Também espero que isso aconteça. Chegou a hora.
No Java 9 também vai entrar o projeto Jigsaw, que foi retirado do 8 porque não ficaria pronto a tempo. Também vai ser uma grande mudança, e muito bem vinda.
Apesar de muita gente ter achado que foi pouco, esse foi o maior update na história da plataforma. Ganhou inclusive do JDK 5, quando foi introduzido generics.
[quote=ViniGodoy]Há um boato de que talvez o Java 9 remova a retro-compatibilidade para versões anteriores ao Java 5. Eu vejo isso de forma positiva, pois permitiria rever a implementação de background dos Generics e acabar com o erasure. Teríamos generics reais (como já existe em C#).
[/quote]
Minha maior preocupação com isso é acontecer o mesmo que aconteceu com o Python 3. Até hoje estão usando o 2.x,se não me engano, por conta de quebras assim.
No .NET, me parece, que você ainda pode ter 2 versões da mesma classe rodando na VM ao mesmo tempo.
Se houvesse algo assim no Java (é a idéia do Jigsaw?), aí acredito que poderíamos ir nessa linha.
A primeira coisa que me veio a mente quando li esse código foi: como o C# consegue garantir que o objeto tenha um construtor default?
Daí eu vi que você precisa definir na assinatura do método que ele tenha um new vazio.
Eu já me contentaria em ter uma forma mais simples de pegar o tipo real usado no método, mesmo que ainda mantivesse a erasure.
[quote=AbelBueno][quote=ViniGodoy]Há um boato de que talvez o Java 9 remova a retro-compatibilidade para versões anteriores ao Java 5. Eu vejo isso de forma positiva, pois permitiria rever a implementação de background dos Generics e acabar com o erasure. Teríamos generics reais (como já existe em C#).
[/quote]
Minha maior preocupação com isso é acontecer o mesmo que aconteceu com o Python 3. Até hoje estão usando o 2.x,se não me engano, por conta de quebras assim.
No .NET, me parece, que você ainda pode ter 2 versões da mesma classe rodando na VM ao mesmo tempo.
Se houvesse algo assim no Java (é a idéia do Jigsaw?), aí acredito que poderíamos ir nessa linha.
A primeira coisa que me veio a mente quando li esse código foi: como o C# consegue garantir que o objeto tenha um construtor default?
Daí eu vi que você precisa definir na assinatura do método que ele tenha um new vazio.
Eu já me contentaria em ter uma forma mais simples de pegar o tipo real usado no método, mesmo que ainda mantivesse a erasure.
[/quote]
No caso do .Net existem várias versões dele instaladas. Eu nunca compreendi a MS nesse sentido.