Java 8 e o fim do PermGen

Teoricamente tudo pode rodar em versões futuras, mas sempre alguma coisa dá problema. Um exemplo são os frameworks que você citou. E nas empresas sempre tem “aqueeeele” sistema legado que se atualizar o Java 1.4 dá pau.

Mas nesse caso é uma alteração no funcionamento interno da jvm, realmente não vejo como isso pode quebrar alguma coisa…

Minha impressão foi que teve uma considerável melhoria na performance na versão 8. Vamos ver nos próximos dias :smiley:

[quote=Adelar]Minha impressão foi que teve uma considerável melhoria na performance na versão 8. Vamos ver nos próximos dias :D[/quote]Impressão vendo algum teste ou você testando?

[quote=sergiotaborda][quote=marcosalex]
Por que só com o Java 9? A Oracle já lançou atualização da linguagem com o Java 7, que estava com o cronograma atrasado mais de 2 anos. E o Java 8 também está vindo com evolução na linguagem, inclusive muitas solicitadas há anos. Não precisa esperar pra ver que o Java acelerou, bastava ter acompanhado os builds de quando a Sun administrava o Java e de agora, é nítida a melhora. O problema é que o Java ficou tempo demais parado, então tem muita coisa pra evoluir ainda.[/quote]

O Java 7 e o 8 são na realidade o mesmo. Deveria ser 7.1 e 7.2. E isso sim mostra o atraso.
O Java 7 ainda foi iniciado quando era a Sun. O processo de compra e o desnorteamento da Oracle que não sabia o que estava comprando ( eles ahavam que tavam comprando o javaCard, mas na realidade estavam comprando o gerenciamento de uma comunidade ativa de milhões de pessoas) atrazou o processo. O JavaFX tb roubou recursos do java SE com a grande asneira que foi o java FX 1, o 2 promete arrazar a concorrencia ( o silverlight e o flash, … ops! perai, o HTML 5 tornou tudo isso obsoleto… )
[/quote]

O Java 7 e 8 surgiram por causa do atraso da Sun. Depois de quase 3 anos atrasado tinha pouca coisa pronta, então a Oracle perguntou à comunidade se preferiam esperar ficar todos so recursos prontos pra lançar, ou lançar um Java 7 com alguns dos recursos e mais tarde o Java 8 com o restante. A comunidade preferiu o ‘plano B’ porque o JDK ficou muito tempo parado. O importante nessa parte é o ritmo de desenvolvimento do Java, que claramente acelerou.

Já o JavaFX foi aposta da Sun, não da Oracle. E a versão 2 foi uma mudança de redirecionamento da Oracle em não competir com o Flash e Silverlight (embora ainda possa ser usado pra isso), mas pra entrar nas aplicações desktop no lugar do Swing, e nesse ponto ele está se saindo melhor.

Eu testando mesmo. Rodei com algumas aplicações pesadas que possuo e foi possível notar a melhoria. Mesmo não sendo a versão definitiva surpreendeu.

Eu testando mesmo. Rodei com algumas aplicações pesadas que possuo e foi possível notar a melhoria. Mesmo não sendo a versão definitiva surpreendeu.[/quote]Bom saber.

Rodou com oq? JBoss? Tomcat? Qual DB?

Eu testando mesmo. Rodei com algumas aplicações pesadas que possuo e foi possível notar a melhoria. Mesmo não sendo a versão definitiva surpreendeu.[/quote]Bom saber.

Rodou com oq? JBoss? Tomcat? Qual DB?[/quote]
Por enquanto tive sucesso só com aplicações JSE mesmo. Tentei rodar o servidor de aplicação que mais utilizo (JBoss 6) mas existem algumas incompatibilidades. Talvez funcione com o JBoss 7. Tomcat, utilizo mas ainda não testei (Tomcat 7). Sobre os bancos, por enquanto foi somente MySQL… não acho que impacte a questão dos bancos, mas de qualquer forma. Estou curioso para ver qual será o impacto das mudanças em banco embutidos.

Eu testando mesmo. Rodei com algumas aplicações pesadas que possuo e foi possível notar a melhoria. Mesmo não sendo a versão definitiva surpreendeu.[/quote]Bom saber.

Rodou com oq? JBoss? Tomcat? Qual DB?[/quote]
Por enquanto tive sucesso só com aplicações JSE mesmo. Tentei rodar o servidor de aplicação que mais utilizo (JBoss 6) mas existem algumas incompatibilidades. Talvez funcione com o JBoss 7. Tomcat, utilizo mas ainda não testei (Tomcat 7). Sobre os bancos, por enquanto foi somente MySQL… não acho que impacte a questão dos bancos, mas de qualquer forma. Estou curioso para ver qual será o impacto das mudanças em banco embutidos.[/quote]O banco é pela questão do driver jdbc. As vezes arreia! =D

Valeu pela info.

[quote=sergiotaborda][quote=ifbcqueiroz]Saudações a todos!

Acredito que muitos já saibam que com o lançamento do JDK 8 a Oracle removeu o espaço de memória chamado de PermGem e substituiu por um novo conceito de gerenciamento chamado de Metaspace, que utiliza a memória nativa, parecido com o encontrados na Oracle JRockit e IBM JVM’s.
[/quote]

Eu já sabia desta noticia, mas agra lendo melhor os detalhes dicou claro que é tudo a mesma coisa. Na realidade é pior. Agora uma aplicação java pode consumir a máquina inteira sem nunca ninguem saber. A modificação foi apenas para poder fundir o hotspot com o JRokit e não para facilitar a nossa vida.É a Oracle fazendo 'arte"… no mau sentido. Vamos ver no que isso no mundo real. Logo para começar vai dar dor de cabeça para quem nunca usou outra jvm senão o hotspot e estava habituado ao OutOMemoryError[/quote]

Não tem arte nenhuma no mau sentido. Eles precisam corrigir toda essa cagada que se extende por anos que deixa a jvm atrás das demais tecnologias de mercado. Esse conceito de “vm” caiu por terra a anos. O que existe hoje são compiladores inteligentes.

[quote=Hebert Coelho][quote=Adelar]…[/quote]O banco é pela questão do driver jdbc. As vezes arreia! =D

Valeu pela info.[/quote]
Não tinha pensado nisso. Bem notado.
Já notei que foram alteradas algumas bibliotecas utilizadas por servidores. Bom que liberar uma versão já nos deixa preparados para as mudanças, ou não :smiley:

Um ponto do Java 5 nao e retrocompativel com 1.4, então não entendi esta paranoia que o 8 ou 9 pode não funcionar com 6 e 7, isto já é uma verdade, começou em X versão vc pode subir a JVM, mas não pode descer.

Quanto a não ter permgen é um alivio tremendo, quando trabalhei em um projeto com SOLR que tinha alguns indices na casa dos gigas, o permgen quebrava e só dava para descobrir em modo produção, é um efeito surpresinha que vai sumir ! acho isto ótimo.

Então sim estou muito feliz com todos os rumos que estamos tomando.

[quote=renatoelias]Um ponto do Java 5 nao e retrocompativel com 1.4, então não entendi esta paranoia que o 8 ou 9 pode não funcionar com 6 e 7, isto já é uma verdade, começou em X versão vc pode subir a JVM, mas não pode descer.[/quote]Sério? Eu já trabalhei em aplicação que rodava em JDK 4 e 5.

De onde você tirou essa informação?

usa generics (1.5) e volta para 1.4

[quote=renatoelias]http://en.wikipedia.org/wiki/Java_version_history#J2SE_1.4_.28February_6.2C_2002.29

usa generics (1.5) e volta para 1.4[/quote]Se for assim, nenhuma versão vai vir a ser retro compatível.

Se você pegar coisa da versão nova e colocar na velha, não vai funcionar nunca… -_-’’

Fala sério né?

O x da questão é do 4 rodar na 5, da 5 na 6… e assim vai. Isso é o que não pode dar problema…

Tem previsão já de lançamento? :-o

Veja o cronograma de lançamento em:

http://openjdk.java.net/projects/jdk8/milestones

Previsto para 2013/09/09

Valeu, vou dar uma olhada… :shock:

Tem muita coisa que as outras linguagens possuem e o JAva tinha ficado pra trás, agora ele finalmente vem implementando e melhorando. Java 7 já avançou alguns pontos, agora o Java 8 vem com mais melhorias. E o roadmap do Java 9 promete muito.

Esse permgen é uma alternativa muito antiquada e já era hora de tirar. Boa parte do consumo excessivo de memória está aí. Os motores novos de javascript como o v8 fazem isso bem melhor que a jvm. Vai ser uma mudança muito boa e aguardada.

Estava olhando as notícias, vendo a palava PermGen, me chamou a atenção, pois a alguns dias atrás, uma aplicação funcionava em minha máquina, após passá-la para um colega, ocorreu erro ao executar, alegando que a memória PermGen havia sido esgotada, pesquisei o erro, e a solução que ofereciam deu certo, compilei o jar aumentando esta memória, com o comando java -jar -XX:MaxPermSize=256m mas confesso que não entendi o funcionamento esta memória, quando ela é utilizada e por que, sou certificado em java, e no livro que li, as diferenças mencionadas era heap e pilha, pelo que me lembre não havia citação desta memória, se puderem me esclarecer o por que ela existe?

Obrigado.