Seja bem vindo ao Fórum do JavaFree.org
Aqui você irá encontrar respostas para TUDO o que você precisa sobre java.
Deseja participar? Crie sua conta ou efetue seu login
Hotspot é uma tecnologia de otimização dinâmica, comprada pela Sun para aumentar a performance da JVM. Página no java.sun.com: http://java.sun.com/products/hotspot/
Nos compiladores tradicionais (nativos), todas as otimizações são feitas em tempo de compilação, reordenando instruções, colocando métodos inline (cópia das instruções deste método no lugar da chamada), etc. É claro que isto só é possível em linguagens do tipo C++, cujo resultado final da compilação é um único arquivo, onde estas otimizações podem bagunçar com toda a estrutura de classes sem afetar o resultado final do processamento.
No Java, esta estratégia não funciona, pois as classes são compiladas em arquivos separados. Foram então criados os compiladores JIT (just-in-time), que pegam o bytecode e traduzem tudo de uma vez pra linguagem de máquina antes da execução, e esta é a estratégia usada pela maioria das JVMs existentes. O problema desta abordagem é a demora no startup. Isso também afeta o nível de otimização, pois o usuário não pode ficar 3 minutos esperando o compilador, toda vez que iniciar o programa, então não são feitas todas as otimizações possíveis.
No Hotspot, o esquema é um pouco mais complexo. Primeiro, a aplicação é executada em modo interpretado, isto é, não é feita nenhuma otimização inicial. Enquanto a aplicação roda, são feitas estatísticas de runtime, verificando quais são os pontos mais executados do programa (hotspots). Estes trechos, então, são fortemente otimizados, utilizando técnicas parecidas com as dos compiladores tradicionais. E tudo isso em runtime! A tecnologia Hotspot utiliza a idéia de que apenas 10% do código é executado em 90% do tempo, e a otimização destes pontos isolados permitem um ganho de performance, teoricamente, até maior do que a compilação estática (tradicional), pois os dados analizados são obtidos da execução real do programa.
Nas versões posteriores da JVM, foram acrescentadas mais estratégias de otimização, incluindo no mecanismo de GC, que genericamente são incluídos no pacote da Hotspot.
Por exemplo, em modo servidor, a JVM é otimizada para programas de longa duração, onde o startup time não é tão importante. Já em modo client, as otimizações levam em conta o tempo que a aplicação leva para iniciar, para que o usuário perceba o mínimo possível a carga inicial da JVM.
No Garbage Collector, há também várias estratégias de coleta. Existe a Parallel Copying Collector, otimizada para máquinas multiprocessadas (com mais de um processador). Ela roda o GC em paralelo com a aplicação, em outro processador. A estratégia mais falada ultimamente é a Generational Copying Collector. Esta separa a heap em duas partes, uma para objetos de vida curta (por exemplo, variáveis de escopo estritamente local) e outra para objetos de vida longa (objetos cujas referências se mantém acessíveis por um longo tempo). O segmento de vida curta é coletado frequentemente, e ao mesmo tempo seu espaço de memoria é compactado. Caso um objeto sobreviva, este é copiado para o segmento de longa vida, que é coletado com uma frequencia menor, utilizando outro algoritmo.
Apenas para deixar claro: HotSpot é o nome da VM da Sun. Assim como JRockit é a da BEA. Dentro da VM temos o JIT, o GC, os bagulinhos de Thread e outros algoritmos.
Na verdade um objeto não sobrevive, mas sim o GC verifica que:
GC: "Pow 'objeto', já passei por você 5.000 vezes e você continua ae, cheio das referências. Quer saber? Vou mandar você pro segmento de vida longa. Assim não verifico você a toda hora." Object: "Ok! Combinado. Você me deixa em paz, e eu deixo você com menos uma encomodação. :)"
Ou seja, o algoritmo faz a contagem de vezes que fez verificação de referencias de tal objeto e caso o valor atinja um valor mínimo, este objeto então é enviado para a geração velha. :)
JIT não está relacionada ao Garbage Collector. Tanto que existe JIT Server e JIT Client na HotSpot.
Um serve para otimizar chamadas constantes a classes/métodos. O outro serve para gerenciar o uso de memória.
Um bom teste para ver o tempo que o JIT demora para compilar o bytecode para linguagem de máquina é passar o parâmetro -XX:+PrintCompilation e o parâmetro -XX:CompileThreshold=1.
Execute a VM sobre uma classe simples: HelloWorld.
O primeiro parâmetro vai fazer o debug da compilação JIT. O segundo configurou a HotSpot para compilar os métodos que forem chamados 1 vez. Ou seja, vai demorar pra caramba pra imprimir o HelloWorld. :) (com ou sem o debug).
Para a HotSpot client (-client), esse valor é de 1.500 chamadas. Ou seja, um método só vai ser carregado para JIT depois de 1500 invocações. Na HotSpot Server, este valor aumenta para 10.000.
O assunto é amplo, grande, e interessante para quem quiser ter todos os detalhes sobre como melhorar a performance da VM. Lembrando que para cada caso, existe uma configuração. Não há a fórmula mágica. Mas uma dica inicial é: configure o heap inicial e o heap maximo para o mesmo tamanho.
$ java -Xms128m -Xmx128m... 128Mbytes de heap.
O porquê disso? Assim a VM não precisa ficar pensando: "Será que vou ter que aumentar o heap? Ok, vamos lá realocar mais espaço..."
:) EOF
_________________ Se é tecnologia Java, é Free! Consultoria é pago!
Consulte os parâmetros para a HotSpot. Dependendo da sua arquitetura (hardware e SO), alguns parâmetros podem melhorar a performance.
_________________ Se é tecnologia Java, é Free! Consultoria é pago!
Se a execução do HelloWorld estiver demorando muito, tente começar passando 10 no CompileThreshold, e entao vá diminuindo o valor. _________________ Se é tecnologia Java, é Free! Consultoria é pago!
Foram expostos alguns pontos que estavam um pouco imprecisos, inclusive da minha parte, então vou comentar um pouco a respeito:
miojo:
Apenas para deixar claro: HotSpot é o nome da VM da Sun.
Hotspot originalmente era a tecnologia de otimização, comprada pela Sun de uma outra empresa, e que inicialmente fazia parte de um interpretador de Eiffel (outra linguagem orientada a objetos). Hoje o termo é usado no nome da JVM da Sun, provavelmente pelo appeal.
miojo:
Na verdade um objeto não sobrevive, mas sim o GC verifica que:
GC: "Pow 'objeto', já passei por você 5.000 vezes e você continua ae, cheio das referências. Quer saber? Vou mandar você pro segmento de vida longa. Assim não verifico você a toda hora." Object: "Ok! Combinado. Você me deixa em paz, e eu deixo você com menos uma encomodação. "
Ou seja, o algoritmo faz a contagem de vezes que fez verificação de referencias de tal objeto e caso o valor atinja um valor mínimo, este objeto então é enviado para a geração velha.
ronaldtm:
O segmento de vida curta é coletado frequentemente, e ao mesmo tempo seu espaço de memoria é compactado.
Do whitepaper: "A generational collector takes advantage of the fact that in most programs the vast majority of objects (often greater than 95%) are very short-lived (for example, they are used as temporary data structures). By segregating newly created objects into an object "nursery," a generational collector can accomplish several things. First, because new objects are allocated contiguously in stack-like fashion in the object nursery, allocation becomes extremely fast, since it involves merely updating a single pointer and performing a single check for nursery overflow. Secondly, by the time the nursery overflows, most of the objects in the nursery are already "dead," allowing the garbage collector to simply move the few surviving objects elsewhere, and avoid doing any reclamation work for dead objects in the nursery."
Aqui eu corrijo um erro meu. Desculpem, eu estava com pressa. No meu primeiro post, eu disse que a memória da área de vida curta é compactada, o que não é verdade, pois o custo da compactação é muito alto. O que eles fazem é alocar os objetos sequencialmente, e quando a área reservada acaba, eles voltam ao começo, verificando se os objetos alocados estão "mortos", ou seja, já estão elegíveis para a coleta de lixo, ou "vivos", ou seja, que ainda têm referências externas e não podem ser coletados. Os objetos mortos são simplesmente sobrescritos, e os objetos vivos são movidos para a área de vida longa. Deste modo, a alocação é bem rápida, sem a necessidade de se manter listas de áreas livres (quem já estudou sistemas operacionais deve saber o que é isso: "best-fit", "first-fit", etc).
No whitepaper eles usam estes termos, "dead", "alive" e "surviving objects", por isso eu usei "sobreviventes", desculpem qualquer confusão.
miojo:
JIT não está relacionada ao Garbage Collector. Tanto que existe JIT Server e JIT Client na HotSpot.
Do whitepaper:
"The Server and the Client VMs are similar, except that the Server VM has been specially tuned to maximize peak operating speed. It is intended for executing long-running server applications, for which having the fastest possible operating speed is generally more important than having a fast start-up time or smaller runtime memory footprint.
The Client VM compiler serves as an upgrade for both the "classic" virtual machine and the just-in-time (JIT) compilers used by previous versions of the Java SDK. The Client VM offers improved runtime performance for applications and applets. The Java HotSpot Client VM has been specially tuned to reduce application start-up time and memory footprint, making it particularly well suited for client environments. In general, the client system is better for GUIs. "
JIT e Hotspot são na verdade os compiladores utilizados na execução do bytecode pela JVM. Explico, compiladores não de java para bytecode, mas de bytecode para linguagem de máquina nativa.
Compiladores JIT compilam (otimizam) o código uma vez só, utilizando técnicas de compiladores estáticos para otimizar o máximo possível em um tempo aceitável.
A diferença do compilador Hotspot é que ele pode otimizar, "desotimizar" e reotimizar o código dinamicamente, dependendo do modo de utilização de cada trecho em runtime.
E a diferença entre "Client" e "Server" são as otimizações feitas por default. O Server pode demorar um pouco mais na otimização, pois o que interessa é o pico de utilização, já o Client deve ser mais rápido no início da execução, para melhorar a experiência interativa do usuário.
JIT e Hotspot são na verdade os compiladores utilizados na execução do bytecode pela JVM. Explico, compiladores não de java para bytecode, mas de bytecode para linguagem de máquina nativa.
Novamente, JIT é uma "idéia", um pattern, um algoritmo, etc... HotSpot é o produto, o nome, a marca (neste caso, da Sun). É como "chocolate" e "Nescau". _________________ Se é tecnologia Java, é Free! Consultoria é pago!
Novamente, JIT é uma "idéia", um pattern, um algoritmo, etc... HotSpot é o produto, o nome, a marca (neste caso, da Sun). É como "chocolate" e "Nescau".
Novamente, JIT é a técnica utilizada em várias implementações da JVM. Não é exatamente uma idéia, nem um algoritmo específico (sobre o "pattern", eu não vou nem falar, se não a gente não acaba essa discussão nunca), mas sim um tipo de interpretador/compilador que compila o código para linguagem de máquina logo antes da execução (o que inclusive é a razão do nome: just-in-time = logo antes... ou mais ou menos isso). Hotspot é sim uma marca da Sun, mas também é o nome dado à tecnologia usada na implementação das novas JVMs.
JIT - Short for just-in-time compiler, a code generator that converts Java bytecode into machine language instructions. Some Java Virtual Machines (VMs), including the VM in the Netscape Navigator browser, include a JIT in addition to a Java interpreter. Java programs compiled by a JIT generally run much faster than when the bytecode is executed by an interpreter.
(...) Just-in-time (JIT) compilers are essentially fast traditional compilers that translate the Java technology bytecodes into native machine code on-the-fly.(...)
There are several problems with JIT compilation.(...) if it is not very fast, then the user will perceive a significant delay in the startup of a program (...)even if a JIT compiler had time to perform full optimization, such optimizations are less effective for the Java programming language than for traditional languages like C and C++.(...)
(...)
As a result, any attempt to achieve fundamental advances in Java programming language performance must provide non-traditional answers (...)
The Java HotSpot VM architecture addresses the Java programming language performance issues described above by using adaptive optimization technology.
Leiam os whitepapes. Apesar de um pouco longos e só disponíveis em inglês, são realmente interessantes. E leiam na ordem: 1.3.1, 1.4.0 e 1.4.1, pois dá pra perceber a evolução gradual da tecnologia.
E mais uma correção: Os JIT não compilam todo o código de uma vez, mas sim método por método, logo antes de serem chamados.
Eu estou com um problema justamente nisso, mesmo que eu passe as configurações Xmn, Xms e Xmx, no máximo da minha maquina coisa de 2Gb, não consigo visualizar o que preciso estou usando java com o Jogl e preciso formar imagens em 3 dimensões, com tamanhos meu grandes do tipo 201X201X201...
Anunciante
psb Offline
Posts: 99
Qual a sua relação com a JAVA VIRTUAL MACHINE?
E o GARBAGE COLECTOR, o que tem haver com a hotspot ?
Nos a usamos, todos os dias no desenvolvimeno de nossas aplicações?
Porque a sun pantentiou essa tecnologia?
Não e pergunta de prova,
E sim uma curiosidade de muitas pessoas aqui?
Vamos respondam galera do JAVA FREE
Abraços..
ronaldtm Offline
Posts: 2299
Hotspot é uma tecnologia de otimização dinâmica, comprada pela Sun para aumentar a performance da JVM. Página no java.sun.com: http://java.sun.com/products/hotspot/
Nos compiladores tradicionais (nativos), todas as otimizações são feitas em tempo de compilação, reordenando instruções, colocando métodos inline (cópia das instruções deste método no lugar da chamada), etc. É claro que isto só é possível em linguagens do tipo C++, cujo resultado final da compilação é um único arquivo, onde estas otimizações podem bagunçar com toda a estrutura de classes sem afetar o resultado final do processamento.
No Java, esta estratégia não funciona, pois as classes são compiladas em arquivos separados. Foram então criados os compiladores JIT (just-in-time), que pegam o bytecode e traduzem tudo de uma vez pra linguagem de máquina antes da execução, e esta é a estratégia usada pela maioria das JVMs existentes. O problema desta abordagem é a demora no startup. Isso também afeta o nível de otimização, pois o usuário não pode ficar 3 minutos esperando o compilador, toda vez que iniciar o programa, então não são feitas todas as otimizações possíveis.
No Hotspot, o esquema é um pouco mais complexo. Primeiro, a aplicação é executada em modo interpretado, isto é, não é feita nenhuma otimização inicial. Enquanto a aplicação roda, são feitas estatísticas de runtime, verificando quais são os pontos mais executados do programa (hotspots). Estes trechos, então, são fortemente otimizados, utilizando técnicas parecidas com as dos compiladores tradicionais. E tudo isso em runtime! A tecnologia Hotspot utiliza a idéia de que apenas 10% do código é executado em 90% do tempo, e a otimização destes pontos isolados permitem um ganho de performance, teoricamente, até maior do que a compilação estática (tradicional), pois os dados analizados são obtidos da execução real do programa.
Nas versões posteriores da JVM, foram acrescentadas mais estratégias de otimização, incluindo no mecanismo de GC, que genericamente são incluídos no pacote da Hotspot.
Por exemplo, em modo servidor, a JVM é otimizada para programas de longa duração, onde o startup time não é tão importante. Já em modo client, as otimizações levam em conta o tempo que a aplicação leva para iniciar, para que o usuário perceba o mínimo possível a carga inicial da JVM.
No Garbage Collector, há também várias estratégias de coleta. Existe a Parallel Copying Collector, otimizada para máquinas multiprocessadas (com mais de um processador). Ela roda o GC em paralelo com a aplicação, em outro processador. A estratégia mais falada ultimamente é a Generational Copying Collector. Esta separa a heap em duas partes, uma para objetos de vida curta (por exemplo, variáveis de escopo estritamente local) e outra para objetos de vida longa (objetos cujas referências se mantém acessíveis por um longo tempo). O segmento de vida curta é coletado frequentemente, e ao mesmo tempo seu espaço de memoria é compactado. Caso um objeto sobreviva, este é copiado para o segmento de longa vida, que é coletado com uma frequencia menor, utilizando outro algoritmo.
Para informações mais completas, consultem os whitepapers em http://java.sun.com/products/hotspot/.
Tetsuo
miojo Offline
Posts: 1355
Apenas para deixar claro: HotSpot é o nome da VM da Sun. Assim como JRockit é a da BEA. Dentro da VM temos o JIT, o GC, os bagulinhos de Thread e outros algoritmos.
Na verdade um objeto não sobrevive, mas sim o GC verifica que:
GC: "Pow 'objeto', já passei por você 5.000 vezes e você continua ae, cheio das referências. Quer saber? Vou mandar você pro segmento de vida longa. Assim não verifico você a toda hora."
Object: "Ok! Combinado. Você me deixa em paz, e eu deixo você com menos uma encomodação. :)"
Ou seja, o algoritmo faz a contagem de vezes que fez verificação de referencias de tal objeto e caso o valor atinja um valor mínimo, este objeto então é enviado para a geração velha. :)
JIT não está relacionada ao Garbage Collector. Tanto que existe JIT Server e JIT Client na HotSpot.
Um serve para otimizar chamadas constantes a classes/métodos. O outro serve para gerenciar o uso de memória.
Um bom teste para ver o tempo que o JIT demora para compilar o bytecode para linguagem de máquina é passar o parâmetro -XX:+PrintCompilation e o parâmetro -XX:CompileThreshold=1.
Execute a VM sobre uma classe simples: HelloWorld.
O primeiro parâmetro vai fazer o debug da compilação JIT. O segundo configurou a HotSpot para compilar os métodos que forem chamados 1 vez. Ou seja, vai demorar pra caramba pra imprimir o HelloWorld. :) (com ou sem o debug).
Para a HotSpot client (-client), esse valor é de 1.500 chamadas. Ou seja, um método só vai ser carregado para JIT depois de 1500 invocações. Na HotSpot Server, este valor aumenta para 10.000.
O assunto é amplo, grande, e interessante para quem quiser ter todos os detalhes sobre como melhorar a performance da VM. Lembrando que para cada caso, existe uma configuração. Não há a fórmula mágica. Mas uma dica inicial é: configure o heap inicial e o heap maximo para o mesmo tamanho.
$ java -Xms128m -Xmx128m... 128Mbytes de heap.
O porquê disso? Assim a VM não precisa ficar pensando: "Será que vou ter que aumentar o heap? Ok, vamos lá realocar mais espaço..."
:) EOF
_________________
Se é tecnologia Java, é Free! Consultoria é pago!
Blog do Bruno Borges
miojo Offline
Posts: 1355
Precisando melhorar a performance do seu servidor J2EE?
http://java.sun.com/docs/hotspot/VMOptions.html
Consulte os parâmetros para a HotSpot. Dependendo da sua arquitetura (hardware e SO), alguns parâmetros podem melhorar a performance.
_________________
Se é tecnologia Java, é Free! Consultoria é pago!
Blog do Bruno Borges
miojo Offline
Posts: 1355
Se a execução do HelloWorld estiver demorando muito, tente começar passando 10 no CompileThreshold, e entao vá diminuindo o valor.
_________________
Se é tecnologia Java, é Free! Consultoria é pago!
Blog do Bruno Borges
ronaldtm Offline
Posts: 2299
Miojo, muito obrigado pelas dicas de performance.
Foram expostos alguns pontos que estavam um pouco imprecisos, inclusive da minha parte, então vou comentar um pouco a respeito:
Hotspot originalmente era a tecnologia de otimização, comprada pela Sun de uma outra empresa, e que inicialmente fazia parte de um interpretador de Eiffel (outra linguagem orientada a objetos). Hoje o termo é usado no nome da JVM da Sun, provavelmente pelo appeal.
Do whitepaper: "A generational collector takes advantage of the fact that in most programs the vast majority of objects (often greater than 95%) are very short-lived (for example, they are used as temporary data structures). By segregating newly created objects into an object "nursery," a generational collector can accomplish several things. First, because new objects are allocated contiguously in stack-like fashion in the object nursery, allocation becomes extremely fast, since it involves merely updating a single pointer and performing a single check for nursery overflow. Secondly, by the time the nursery overflows, most of the objects in the nursery are already "dead," allowing the garbage collector to simply move the few surviving objects elsewhere, and avoid doing any reclamation work for dead objects in the nursery."
Aqui eu corrijo um erro meu. Desculpem, eu estava com pressa. No meu primeiro post, eu disse que a memória da área de vida curta é compactada, o que não é verdade, pois o custo da compactação é muito alto. O que eles fazem é alocar os objetos sequencialmente, e quando a área reservada acaba, eles voltam ao começo, verificando se os objetos alocados estão "mortos", ou seja, já estão elegíveis para a coleta de lixo, ou "vivos", ou seja, que ainda têm referências externas e não podem ser coletados. Os objetos mortos são simplesmente sobrescritos, e os objetos vivos são movidos para a área de vida longa. Deste modo, a alocação é bem rápida, sem a necessidade de se manter listas de áreas livres (quem já estudou sistemas operacionais deve saber o que é isso: "best-fit", "first-fit", etc).
No whitepaper eles usam estes termos, "dead", "alive" e "surviving objects", por isso eu usei "sobreviventes", desculpem qualquer confusão.
Do whitepaper:
"The Server and the Client VMs are similar, except that the Server VM has been specially tuned to maximize peak operating speed. It is intended for executing long-running server applications, for which having the fastest possible operating speed is generally more important than having a fast start-up time or smaller runtime memory footprint.
The Client VM compiler serves as an upgrade for both the "classic" virtual machine and the just-in-time (JIT) compilers used by previous versions of the Java SDK. The Client VM offers improved runtime performance for applications and applets. The Java HotSpot Client VM has been specially tuned to reduce application start-up time and memory footprint, making it particularly well suited for client environments. In general, the client system is better for GUIs. "
JIT e Hotspot são na verdade os compiladores utilizados na execução do bytecode pela JVM. Explico, compiladores não de java para bytecode, mas de bytecode para linguagem de máquina nativa.
Compiladores JIT compilam (otimizam) o código uma vez só, utilizando técnicas de compiladores estáticos para otimizar o máximo possível em um tempo aceitável.
A diferença do compilador Hotspot é que ele pode otimizar, "desotimizar" e reotimizar o código dinamicamente, dependendo do modo de utilização de cada trecho em runtime.
E a diferença entre "Client" e "Server" são as otimizações feitas por default. O Server pode demorar um pouco mais na otimização, pois o que interessa é o pico de utilização, já o Client deve ser mais rápido no início da execução, para melhorar a experiência interativa do usuário.
Tetsuo
miojo Offline
Posts: 1355
Novamente, JIT é uma "idéia", um pattern, um algoritmo, etc... HotSpot é o produto, o nome, a marca (neste caso, da Sun). É como "chocolate" e "Nescau".
_________________
Se é tecnologia Java, é Free! Consultoria é pago!
Blog do Bruno Borges
ronaldtm Offline
Posts: 2299
Novamente, JIT é a técnica utilizada em várias implementações da JVM. Não é exatamente uma idéia, nem um algoritmo específico (sobre o "pattern", eu não vou nem falar, se não a gente não acaba essa discussão nunca), mas sim um tipo de interpretador/compilador que compila o código para linguagem de máquina logo antes da execução (o que inclusive é a razão do nome: just-in-time = logo antes... ou mais ou menos isso). Hotspot é sim uma marca da Sun, mas também é o nome dado à tecnologia usada na implementação das novas JVMs.
http://www.webopedia.com/TERM/J/JIT.html
http://java.sun.com/products/hotspot/docs/whitepaper/Java_HotSpot_WP_Final_4_30_01.html#pgfId=1082363
Leiam os whitepapes. Apesar de um pouco longos e só disponíveis em inglês, são realmente interessantes. E leiam na ordem: 1.3.1, 1.4.0 e 1.4.1, pois dá pra perceber a evolução gradual da tecnologia.
E mais uma correção: Os JIT não compilam todo o código de uma vez, mas sim método por método, logo antes de serem chamados.
http://wwws.sun.com/software/solaris/jit/
Tetsuo
leckter Offline
Posts: 3
Eu estou com um problema justamente nisso, mesmo que eu passe as configurações Xmn, Xms e Xmx, no máximo da minha maquina coisa de 2Gb, não consigo visualizar o que preciso estou usando java com o Jogl e preciso formar imagens em 3 dimensões, com tamanhos meu grandes do tipo 201X201X201...
Alguém tem alguma idéia...
Relacionados
Weblogic e JDK1.4 http://javafree.uol.com.br/topic-815-Weblogic-e-JDK14.html Iniciando em Java http://javafree.uol.com.br/topic-850964-Iniciando-em-Java.html Os mais lidos. http://javafree.uol.com.br/topic-851669-Os-mais-lidos.html Advantages of PHP Over Java http://javafree.uol.com.br/topic-8656-Advantages-of-PHP-Over-Java.html Teria como rodar uma aplicação no Jboss sem deploy ??? http://javafree.uol.com.br/topic-852915-Teria-como-rodar-uma-aplicacao-no-Jboss-sem-deploy.html Músicas para programar! http://javafree.uol.com.br/topic-852978-Musicas-para-programar.html Os posts mais legais do JavaFree. http://javafree.uol.com.br/topic-857239-Os-posts-mais-legais-do-JavaFree.html Processador Com j2me imbutido http://javafree.uol.com.br/topic-850340-Processador-Com-j2me-imbutido.html JBOSS muito lento http://javafree.uol.com.br/topic-12684-JBOSS-muito-lento.html
Anunciante