It’s been some time (around 3 weeks and a half now) since I started
to hack rjni. At
first I didn’t think about what integration does really mean: I was
just implementing (quite in a hurry) an idea that popped out during Euruko
03. So I just provided a simple means to use JNI from Ruby and a
(IMHO neat) mapping of Java to Ruby concepts: static methods become class
singleton methods, accessors are created for attributes, etc.
I’ve been thinking of expanding the scope of rjni to cope
with the following issues:
type-safety: as of now, you can crash the interpreter by using
JNI with wrong parameters. This could be prevented but
there’s a performance hit
that’s what you get for using low-level APIs instead of "magical
reflection"
signal handling: Ruby’s threading model uses signals to simulate
threads (green threads). What are the implications when linking to the JVM?
sub-classing Java classes in Ruby and using them from Ruby: already
possible, but not clean enough as there’s a couple things to
consider:
method overloading in Java complicates things on the Ruby side
Java attributes don’t become instance variables (you have to go
through accessors, even inside instance methods)
using Ruby from Java? Involves mapping Ruby’s C API through JNI
then it becomes possible to subclass Java classes in Ruby and use them in
Java…
threads: Ruby’s interpreter is not thread safe; this will be
a problem if using Ruby from Java becomes possible
The signal handling issue is especially problematic since that’s
quite tricky and possibly system- and JVM-dependent. Threads could prove to
be difficult to get right, too.
If you see how to solve these problems (or want to have some fun doing so
:-) contact me at <batsman dot geo at yahoo dot com>.
Previous Topic
