JRuby is an alternate implementation of the Ruby programming language. It is also an embedded language for the Java Virtual machine (JVM). On both of these fronts, we have a set of limitations that a user should be aware of.
When we outline each limitation, we will note whether we think that the limitation is likely to go away and JRuby matures. In some cases, we cannot implement features because the underlying JVM does not allow it. In other cases, it is simply not implemented yet.
Ruby conformance Limitations
This section reflects known incompatibilities between Ruby and JRuby. It is by no means comprehensive. It just reflects larger issues we are aware of. The fact that Ruby does not have a language specification also makes having an exact delta between the two implementations impossible.
- Does not support continuations/bindings.
- These features are simply missing. There is nothing which prevents them from existing short of programmer effort.
- Fine-grained timer.
- Benchmarking code depends on finer grained timings than the JVM supports. This may be solved in a future JVM as there is a JSR on this (which JSR?).
- Identical thread behavior
- Ruby uses green threads to implement the languages threading library. JRuby uses Java threads to implement Thread and friends. Without actually implementing green threads ourselves, we will not have identical thread behavior. Hopefully, any sane multi-threaded ruby script will work ok in spite of this.
- Missing Posix methods
- The JVM is missing some Posix operations needed by File, Process, etc.. in Ruby. We are now starting to use JNA (yes JNA and not JNI) to add as many of these as JNA can support. For JRuby 1.1 many common ones will be available (e.g. getpid, getgid, getxxx).
- Ruby C extensions
- Any Ruby library which contains C extensions are not supported by JRuby. For the more popular packages we have ported them to be Java extensions. Others can always be ported as well. There are some exotic ideas in how we could possibly support C native extensions, but no one is past the napkin stage on actually implementing it. Rubinius work may provide us with an evenue to supporting them. Until that time consider porting an extension or possibly using a similiar Java technology to do the same thing.