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>.
Read: Ruby/Java integration
Previous Topic
