On Mon, Jan 25, 2010 at 6:29 AM, Aaron Patterson
<aaron / tenderlovemaking.com> wrote:
> I thought FFI was supposed to solve this problem. Is it not?

As Tony mentioned, it solves the problem just fine, except that you
still have to have the right libraries available and permission to use
them. Lots of production deployment environments for Java disallow
loading native libraries because they have a much higher likelihood of
crashing the JVM or circumventing its security policies. Google App
Engine, for example, doesn't allow loading native libraries at all,
and of course any small profile Java environments will often be unable
to use native libs as well (like Android).

> I implore Ruby implementors to support the MRI C api, as it too is part
> of Ruby's api. Think about who you hurt by not letting people reuse
> valuable libraries written in C. :-)

The MRI C API is terrible if you want to implement it for anything
other than MRI. It allows direct pointer access to object internals,
allows you to *write* to objects directly in memory, has absolutely no
consideration for concurrent execution, no abstraction around object
locations in a relocating GC, and no methods or standards for handling
reference lifecycle (that I am aware of). As I've stated before (and
told you) we'd be happy to support a C API that did not include all
the unsafe bits (like accessing array, string, or hash contents
*directly*) and only allows you access to objects via a handle-based
indirection mechanism. It's just a matter of time and effort to
implement it...and there's a bounty to do so :)

Even then, however, it still wouldn't solve the problems of loading
native libraries on secure environments.

I firmly believe the MRI's C API is the #1 thing holding it back. Why
can't we get a better GC in place? Native extensions. Why can't we
have real concurrent threading? Native extensions. Why is it a pain in
the ass to use MRI on environments without a compiler easily
available, like Windows? Native extensions. When used with plain Java
libraries, JRuby works almost identically across all platforms without
modification, without build tools present, and without segfaults. That
beats supporting the current unsafe C API any day.

- Charlie