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!