# JRuby progress and the future **URL:** \ **Category:** Ruby\ **Created:** [March 2, 2006, 8:34pm UTC](https://www.ruby-forum.com/t/jruby-progress-and-the-future/75859 "2006-03-02T20:34:10Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![Charles\_O\_Nutter](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/aeb1de/32.png) [@Charles\_O\_Nutter](https://www.ruby-forum.com/u/Charles_O_Nutter)\ **Post date:** [March 2, 2006, 8:34pm UTC](https://www.ruby-forum.com/t/jruby-progress-and-the-future/75859/1 "2006-03-02T20:34:10Z")
Sorry for the unsolicited promotion of JRuby and my own blog, but I have been keeping a record of updates to JRuby along with musings on the future of Ruby and Java playing together at [http://headius.blogspot.com](http://headius.blogspot.com). For those of you like me, caught between worlds, I will frequently provide updates on the progress of JRuby and the future of Ruby applications running on Java. My post today updates the progress of getting Rails and IRB running, with a long discussion of JRuby’s design goals, performance woes, and promises for the future. Naturally, I’d like an audience, but I’d also like to dispel the continuing rumors that JRuby is “dead”. For those of you completely uninterested in Ruby-on-Java, you can safely disregard this email. 🙂 Thank you! ---
**Author:** ![Charles\_O\_Nutter](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/aeb1de/32.png) [@Charles\_O\_Nutter](https://www.ruby-forum.com/u/Charles_O_Nutter)\ **Post date:** [March 3, 2006, 3:55am UTC](https://www.ruby-forum.com/t/jruby-progress-and-the-future/75859/2 "2006-03-03T03:55:14Z")
Hey Charles: Tim B. mentioned that JRuby uses Java native threads to implement Rubys’ threads. [1] Do you guys have any sort of publically posted comparisons of performance of threading between Ruby & JRuby? I don’t even know enough about concurrency to know what are good ways to measure performance, but I think I’d find it interesting reading anyway. Francis [1] [ongoing by Tim Bray · Ruby on Rome](http://www.tbray.org/ongoing/When/200x/2005/08/31/Ruby-Rome) ---
**Author:** ![Charles\_O\_Nutter](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/aeb1de/32.png) [@Charles\_O\_Nutter](https://www.ruby-forum.com/u/Charles_O_Nutter)\ **Post date:** [March 3, 2006, 5:01am UTC](https://www.ruby-forum.com/t/jruby-progress-and-the-future/75859/3 "2006-03-03T05:01:28Z")
That’s a good question, Francis. I’m afraid no formal comparison of JRuby’s threads versus Ruby’s threads has ever been done. Threading has been both an advantage and a disadvantage of JRuby. - Native threads allow ruby code under JRuby to utilize multiple processors, ultimately scaling better to big iron, but… - A hard 1:1 tie between Ruby and Java threads means that many Ruby thread operations are difficult or impossible to support because Java’s own threads do not support those operations. Cross-threading hacks are a poor substitute for access to and control of a true thread scheduler If we put aside JRuby’s interpreter performance issues for a moment, it would be safe to assume that JRuby’s threading today would in general scale and perform better than C Ruby, since it would automatically provide a truly threaded environment for ruby code. That said, it’s difficult to quantify that performance benefit in light of the current unoptimized JRuby interpreter. You could scale it better, but you’d be scalling a much slower base interpreter. In order to address the second point above, we have chosen to implement our own “green” non-native threading subsystem in JRuby. This will allow us to build a thread scheduler and threading semantics that match the way Ruby wants threads to work. However, since Tim B. and others have expressed a strong interest in keeping JRuby native-threaded, we are planning to back those “green” threads with a configurable pool of natives. For applications that want or warrant true 1:1 threading, there will be no issue…simply turn on 1:1 and it will run as it runs today. For applications that want pure green threads, it will be just as simple; turn it on and all Ruby threads will run in a single Java thread. However, for those middle cases where we want m Ruby threads to be backed by n Java threads, we will also support m:n threading, providing three different mechanisms for scaling up Ruby applications. So in the end, I don’t have any definitive answer to give you. JRuby’s current threading scales better; JRuby’s current slow interpreter does not. JRuby’s threading does not support all Ruby threading operations well currently. All these issues are being addressed in the next six months (or perhaps sooner if we can get Rails running). Does any of this answer your question? – Charles Oliver N. @ [headius.blogspot.com](http://headius.blogspot.com) JRuby Developer @ [jruby.sourceforge.net](http://jruby.sourceforge.net) Application Architect @ [www.ventera.com](http://www.ventera.com) ---
**Author:** ![Charles\_O\_Nutter](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/aeb1de/32.png) [@Charles\_O\_Nutter](https://www.ruby-forum.com/u/Charles_O_Nutter)\ **Post date:** [March 3, 2006, 4:18pm UTC](https://www.ruby-forum.com/t/jruby-progress-and-the-future/75859/4 "2006-03-03T16:18:25Z")
Ahh JSR 223. 223 is, at its core, a more feature-complete and standardized version of the Bean Scripting Framework (BSF). It provides a standard mechanism whereby alternative JVM languages (primarily targetted at so-called “scripting” languages) can be plugged into and interact with Java and the rest of the JVM. BSF provides similar capabilities; you can register a named language interpreter, bind objects into its execution context, and send snippits of code to that interpreter to be executed. 223 mainly standardizes a lot of this and potentially builds that capability into Java out-of-the-box, rather than via a third-party library. There’s shades of not-invented-here, but BSF certainly is showing its age (it does not, for example, use more recent versions of collection classes, nor does it take advantage of recent JVM advancements). 223 will probably be good for Java as a whole, and once it’s physically released we’ll have JRuby connectors for it soon after. We also currently provide our own java integration layers that are arguably simpler and more “ruby-like” than what BSF or 223 provide. There’s something for all tastes, I suppose. 223 does not, however, provide a generic way to hook any arbitrary interpreter such as C Ruby into the JVM. Using any native-language interpreters to manipulate Java objects and the JVM itself requires considerably more work, since plugging native code into the JVM is far from easy. The “rjni” project does exactly that, though I can’t comment on how well it works or whether it’s currently being maintained. ---
**Author:** ![Charles\_O\_Nutter](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/aeb1de/32.png) [@Charles\_O\_Nutter](https://www.ruby-forum.com/u/Charles_O_Nutter)\ **Post date:** [March 3, 2006, 10:15am UTC](https://www.ruby-forum.com/t/jruby-progress-and-the-future/75859/5 "2006-03-03T10:15:36Z")
On 3/2/06, Charles O Nutter [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > For those of you completely uninterested in Ruby-on-Java, you can > safely disregard this email. 🙂 > > Thank you! Thanks for the notice, I’ll keep an eye on your blog. And now we talk about ruby & java, I’ll take the opportunity to ask a question I haven’t had the possibility to answer myself: what will JSR223 give as possibility? Is it a way for ruby (the C version) to access java classes? JSR223 started with a limited scope (web apps) that was widened later on, but up to what point? Raph