<div class="gmail_quote">2011/1/13 Eden Cardim <span dir="ltr"><<a href="mailto:edencardim@gmail.com">edencardim@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
>>>>> "Alexei" == Alexei Znamensky <<a href="mailto:russoz@gmail.com">russoz@gmail.com</a>> writes:<br>
<br>
Alexei> Não exatamente, Eden.<br>
<br>
Alexei> As JVMs de hoje, quase todas, têm algum mecanismo de<br>
Alexei> "recompilação" do bytecode para opcodes nativos da<br>
Alexei> plataforma onde a JVM é executada. As JVMs da Sun^ WOracle<br>
Alexei> fazem isso adaptativamente, enquanto que as da IBM compilam<br>
Alexei> TUDO para nativo, e a execução ocorre em opcodes nativos,<br>
Alexei> não nos virtuais.<br>
<br>
Bom, disso eu não sabia, mas, se tudo é compilado e executado<br>
nativamente, qual o objetivo de se usar uma VM?<br></blockquote><div><br></div><div><disclaimer type="somente uma opiniao, inventada agora, de ressaca e com sono"></div><div>Bom, se olharmos a história da computação, geralmente caminhamos em direção a padronizações.</div>
<div><br></div><div>Se olharmos como era compilação de aplicativos em C/C++, Pascal, etc... (todas as linguagens "não-script"), vamos notar que sempre houve um grande problema de compatibilidades entre fontes escritos para uma plataforma e fontes escritos para outras. Basta pegar o código fonte de um software de certo porte, já portado para diversas plataformas, escrito em C/C++ e olhar a quantidade de diretivas #if / #include / #endif que é necessária para fazer o mesmo ser multi-plataforma, multi-compilador, etc...</div>
<div><br></div><div>Eu sei que o Java não inventou nada, do ponto de vista técnico. Praticamente, senão todas, as tecnologias utilizadas em uma JVM já existiam antes. Mas o maior mérito do Java, IMHO, foi justamente *padronizar* (de fato, não de direito), para as massas, o uso de uma VM, e os benefícios associados a isso: padronizou-se os compiladores e outras ferrametnas de desenvolvimento, padronizou-se binários, etc..</div>
<div><br></div><div>O meu cotidiano no trabalho, right now, consiste, dentre outras coisas, de instalar binários (.class compilados em máquinas Windows/Intel de desenvolvimento) para executar em JVMs que rodam em AIX/PowerPC. Seria muito difícil ter isso sem VMs. Sem VMs, todos os developers (quase que-independentemente da linguagem a ser escolhida) seriam obrigados a usar algum servidor AIX para compilar e testar seu código. Como os ciclos de desenvolvimento, hoje, estão extremamente calcados em tentativa-e-erro (por vários motivos que não vou entrar no mérito agora), o tempo gasto para desenvolver o mesmo código caiu drasticamente, pois o developer pode usar sua CPU e SO baratos para malhar o código e rodar testes unitários, e o binário que ele gera localmente pode ser simplesmente copiado para o servidor de testes, onde será novamente, e mais duramente, sabatinado. Não é preciso recompilar (ou, não seria, mas nunca subestime a estupidez humana).</div>
<div><br></div><div>Por outro lado, VMs têm o custo de performance associado à interpretação/execução dos opcodes virtuais, então com o tempo, os implementadores de JVMs acabaram fazendo essas "traduções" de opcodes virtuais para nativos em tempo de execução, para melhorar esse ponto. Me parece uma evolução quase que "natural" do conceito.</div>
<div><br></div><div>Assim, meio que respondendo ao email que o Otávio mandou enquanto escrevo este, a JVM já está caminhando para ser mais do que "a VM para rodar Java", e está se tornando "a 'Java' (as in 'um nome qualquer') VM, que roda programas em diversas plataformas físicas, em qualquer linguagem original que elas tenham sido feitas". Hence, temos JRuby, Scala, Jython, etc...</div>
<div><br></div><div>Digo mais (sob o risco de polemizar ainda mais o tópico): se o Perl tivesse uma versão que gerasse bytecode no padrão de JVM, aí sim a linguagem iria abocanhar de volta uma gorda e suculenta fatia do mercado (claro que não seria somente isso, não é bala de prata, mas isso ajudaria bastante, IMHO).</div>
<div></disclaimer></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> Alexei> O que não invalida totalmente o seu ponto, pois o<br>
Alexei> programador não tem controle sobre os opcodes nativos<br>
Alexei> gerados (mas até aí, eu faço esse trade-off any day, sem<br>
Alexei> pestanejar).<br>
<br>
Realmente, fica difícil um humano escrever código com desempenho melhor<br>
em tempo hábil.<br></blockquote><div><br></div><div>;-)</div><div><br></div></div>-- <br><font face="georgia, serif">Alexei Znamensky [russoz_gmail_com] [<a href="http://russoz.wordpress.com" target="_blank">russoz.wordpress.com</a>] [<a href="http://www.flickr.com/photos/alexeiz" target="_blank">www.flickr.com/photos/alexeiz</a>]<br>
<span style="border-collapse:collapse"><div>«Only love / Can bring the rain / That makes you yearn to the sky»</div></span></font><br>