From: Charles Oliver Nutter <charles.nutter@...>
Date: 2007-11-11T10:02:47+09:00
Subject: Re: enterprise ruby

Lionel Bouton wrote:
> Robert Klemme wrote the following on 09.11.2007 22:05 :
>> Personally, if I had the resources to invest into this I'd rather
>> spend them on JRuby.  You get a GC with many tweaking options etc.
>> plus native threads.
>>
> 
> Please don't forget that many gems still don't work or don't have
> replacement in JRuby. JRuby is *the* solution for people needing easy
> Ruby <-> Java integration but Ruby with strong Unix ties has its
> benefits too.

The lack of native gems in JRuby has so far not amounted to much of an 
obstacle. Since in normal Ruby code you can go after the Java equivalent 
libraries with ease, there's been very little demand to port over native 
extensiosn.

> I think I'd have to spend quite some time to migrate applications from
> MRI to JRuby: I heavily used ruby-gettext, hpricot, memcache,
> ruby-opengl and I believe most of these use C for library interfaces or
> performance... some utils like rcov probably don't work either with
> JRuby because they probably rely on the same C interface.

I don't think memcache uses C. Hpricot does, but there's a JRuby port 
since it's a Ragel-generated state machine. I don't know about gettext. 
GL could easily be replaced with one of several Java 3D/GL binding 
libraries.

> So as much as I'd like JRuby to succeed even if I don't use it myself
> (currently), people willing to work on MRI (or YARV and Rubinious for
> that matter) are most welcomed to do so too.

I think MRI is mostly a dead end at this point, unlikely to see any 
major perf/scaling improvements anymore. If you're going to focus a lot 
of time on tweaking and improving an implementation, I'd recommend 
helping out one of the really active 1.8-compatible implementations 
(JRuby being the most complete and furthest along) or a 1.9 
implementation (YARV being most complete and furthest along...but we 
have some 1.9 features in JRuby too).

> But maybe there is an efficient way to use JNI to trivially port most of
> these to JRuby. This could motivate my toying with JRuby...

JNI to native extensions is a band-aid at best. The better option is to 
rewrite the libraries in terms of what's readily available on the JVM.

- Charlie