JRuby: é sério!

Posted on April 17, 2007

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!