Rodrigo Kumpera Weblog

O Daniel comentou como fazer o HotSwap funcionar com o oc4j, dai veio o Diego e falou de como isso é coisa velha na plataforma desde a 1.4 – me lembro be de todo maldito beta desse release, que cada um vinha com bugs diferentes no java.nio. Hot Code Replace é uma técnica util, não tanto para debug até, só que é extremamente restritivo e vira motivo de chacota quando comparamos com linguagens dinâmicas.

Linguagens dinâmicas, como Python e Ruby tem a obrigaçào moral de suportar um sistema muito mais dinâmico que Java. Os dois motivos são bem razoaveis: o primeiro que não existem informações de tipos no código da aplicação, logo não existe o problema da assinatura da função mudar de “int f(int)” para “short f(int)”; e tem a vantagem de possuirem runtimes muito mais simples – apenas com um interpretador, lidar com todos os problemas do ponto de vista de um JITer é um caos.

HCR é super importante para o recurso de intrumentação introduzido no java5. Tem um monte de ferramentas de diagnóstico e profiling leves que se baseiam na API java.lang.instrument.

Imagine que sua aplicação em produção está deixando a desejar em termos de performance, mas felizmente ela foi intrumentada em pontos estratégicos para monitorar coisas como tempo de resposta do banco e quais actions do Struts estão causando problemas. Esse troubleshooting ocorre no sistema de produção e quase não orera o sistema – diferente de um profiler.
Não acho que vale muito a pena perder tempo tentando melhorar essa tecnologia, pois é muito complexa. Seria muito mais interessante uma JVM com suporte a isolates super super leves, ao ponto de podermos criar um para cada requisição web que desejássemos processar. Com isso teriamos aquilo que todo programador de cobol e mainframe esfrega com tanto orgulho na nossa cara, a robustes e isolamento a falhas da plataforma deles. Uma requisição web que causa um OOM mata o sistema inteiro, mas se pudessemos utilizar isolates, dava até para dormir melhor com estagiarios trabalhando no projeto.

Por isso que Erlang é a linguagem mineirinha da atualidade, ela vai comendo quieta pelas bordas e vai supreender, nós desenvolvedores de Java, c# e Ruby, pois quando a Intel lançar um processador com 32 cores e o MacPro vier com 8 desses brinquedos nós não vamos ter a menor idéia de como fazer o load do sistema chegar em 10% sem tudo explodir. Se você acha que estou exagerando, os quad-core da intel saem no final desse ano, coisa de 18 meses depois dos primeiros Core 2 Duo e nosso querido Gordon Moore vai continuar acertando.