Eu já publiquei alguns artigos sobre JRuby mas mesmo assim parece que muitas pessoas estão ignorando este assunto mais como “curiosidade”. Mas não se enganem, as equipes lá fora estão bastante sérias. E mais ainda: JRuby não é a única implementação diferente da MRI (Matz Ruby Implementation) ou YARV (a.k.a. Ruby 1.9, de Koichi Sasada). Agora temos XRuby, Rubinius e Ruby.NET, cada um em diferentes estágios de desenvolvimento.

JRuby, é liderado por Charles Nutter e um dos principais desenvolvedores é Ola Bini (o link que coloquei é de seus respectivos blogs, um excelente local para acompanhar esta história).

No dia 5 de março, eles saltaram da versão 0.9.2 para a 0.9.8, sinalizando que a implementação 100% compatível com o Ruby MRI está para sair. Muitos aguardam um lançamento agora mesmo em Maio. E qual o estado atual do JRuby? Para a maioria, o interesse é rodar aplicações web desenvolvidas em Ruby on Rails. Bem, a 0.9.8 sinaliza 98% de compatibilidade com a suíte de testes oficial do Rails e 100% de compatibilidade com a suíte de testes do ActiveRecord, o suficiente para já haver pessoas tentando rodar aplicações em produção com JRuby.

Acompanhar a evolução do JRuby tem sido muito gratificante pelo passo rápido, principalmente graças a desenvolvedores como Ola Bini. Pontos interessante é o suporte a Unicode. Alguns poderiam ingenuamente imaginar “Java suporta UTF-16 internamente, portanto colocar Unicode no JRuby é trivial”. Nem tanto o céu e nem tanto a terra. Não podemos nos esquecer que no MRI, um String é apenas uma cadeia simples de bytes e muitos programas foram escrito com essa premissa em mente. Coloque Unicode como padrão e diversos programas simplesmente quebram. A solução? Algo parecido com o que o novo Rails 1.2 fez com MultiByte : criar um método proxy na classe String e manter os dois métodos em paralelo.

Existem mais pontos negros no caminho. JRuby começou como um interpretador que roda sobre a JVM. No meio do caminho Charles começou a montar um compilador, capaz de gerar byte-code Java, em vez de interpretar arquivos .rb. A vantagem: com um interpretador quase 100% compatível com o MRI, ele pôde escolher uma técnica de Just-In-Time (JIT) compilation, ou seja, geração de byte-codes em tempo real. Toda vez que o compilador falhar em gerar o byte-code, ele pode decair para a interpretação. Para se ter uma idéia, somente a interpretação ainda é um pouco mais lenta que o MRI, em benchmarks – que foram feitos especialmente para o Ruby 1.9. Mas com a compilação JIT ativada os números ficam muito favoráveis para JRuby, chegando a ser duas vezes mais rápido em muitos casos. Ou seja, performance ainda é uma preocupação mas está longe de ser algo vexatório, muito pelo contrário: está extraordinário principalmente se considerar que o projeto mal tem 1 ano de idade.

Na área de compilação para byte-codes temos o XRuby também. O projeto de Xue Yong Zhi é o menos ambicioso e o que tem menos recursos e visibilidade no momento. Eles pretendem tentar rodar Rails em XRuby até o fim do ano. Mas eles tem algo que JRuby talvez aproveite em uma versão pós-1.0: o parser de seu compilador talvez seja muito melhor que do JRuby. Charles e Ola estão avaliando.

Outro caminho negro tanto para JRuby quanto XRuby: as bibliotecas nativas. Muitas das bibliotecas atuais de Ruby são escritos em C. Se fossem todas escritas em Ruby, seria trivial portá-las para a JVM. Mas como estão em C elas precisam ser re-implementadas. Exemplo disso é a engine de Regular Expressions. Alguém poderia ingenuamente dizer “Java tem o java.util.regex”. Infelizmente Regex não é um padrão rigoroso e existem muitas diferenças entre cada implementação. Pegue um programa que dependa de coisas que só existem na MRI e elas quebram na versão Java. Ola Bini está ocupado reimplementando a mesma engine em Java agora.

Este artigo da InfoQ tem mais detalhes. E sobre a performance atual do JRuby sugiro ler este post do blog Headius, de Charles. Aliás, acredito que todos saibam que Charles trabalha para a Sun. Espere grandes progressos no JRuby. Rodar Rails em Glassfish ou outro container de servlets não é uma promessa longíngua. Estamos basicamente a poucas semanas de uma versão 1.0.

Como podem ver, JRuby é sério, e está chegando!

comentários deste blog disponibilizados por Disqus