The power of JRuby

It’s true that I’m not the qualified guy to talk about Java’s power,as it has been 2 years since i last practiced it, but i feel like i have to communicate my thoughts to the people that didn’t give JRuby a trial yet, and why they should do so.
If you never worked with Java before, then don’t panic, cause in these article i would list several reasons why JRuby is so powerful even if you don’t know anything about Java.
Lemme start listing all the points that makes me feel the power of JRuby; the order here is irrelevant as i do believe that every point listed bellow has somehow the same rank that others might have:

1- Mixing the power of Java with the power of Ruby.
2- A faster(if not the fastest) Ruby implementation.
3- Native Threads.
4- Support for Foreign Function Interface(FFI).
5- Make use of the JVM (HotSpot).
6- Have a great community and support.

Mixing the power of Java with the power of Ruby

There are thousands of Java packages that are ready for you to use, and according to TIOBE, Java is continuing to be the most popular language, so why don’t you make use of the existing Java packages, and use them inside your code?
For example, you can use the swing package(a very powerful GUI package) inside your ruby code, the following snippet of code is taken from the samples folder in the JRuby distribution:

You can also reference ruby code inside Java code, examples could be found here.

A faster(if not the fastest) Ruby implementation

JRuby team consider it a bug if they are slower on something than MRI, thus they keep enhancing the performance of JRuby.
According to Antonio Cangiano, the guy behind the great ruby shootout here and here:

Ruby 1.9 and JRuby are very close, respectively 2.5 and 1.9 faster than Ruby 1.8.7 (from source) on these benchmarks.

Surprisingly JRuby was slower than ruby 1.8.6 last year, but now it’s competeing 1.9 in terms of speed.
Charles Nutter the JRuby team leader commented on that saying:

I’m looking forward to seeing another update once JRuby finishes 1.9 support, since these JRuby numbers don’t reflect execution and library optimizations 1.9 provides. I expect that JRuby in 1.9 mode will perform much closer to Ruby 1.9.

Until then, it’s good to hear we’re the fastest 1.8 implementation. Thanks again!

Native Threads

The current ruby interpreter which is called MRI supports green threads, as opposed to JRuby which supports native threads.
Green threads are managed by VM, not by the operating system, and thus, by using them you lose a significant power called “concurrency” which is available to multi core processors, that’s because the VM will continue to use one core to serve the whole threads, as opposed to native threads which will use the full power of multi core processor, by being assigned to the available cores.
In general an application might be IO-bounded(lots of IO operations, like logging and database related ones) or CPU-bounded(lots of computation), and while green threads are useful for the IO-bounded applications, they are not useful for the CPU-bounded ones.
A CPU-bonded applications consumes the CPU, and thus you can increase the speed of your program by having multi core processor, but thus you need native threaded applications, to make use of the available cores.
JRuby comes to rescue as it supports native threads, and thus you have full concurrency when you have multi core processors.

Support for Foreign Function Interface(FFI)

According to wikipedia a Foreign Function Interface (or FFI) is :

A mechanism by which a program written in one programming language can call routines or make use of services written in another.

Why would a one need that? well many gems that we use like Rmagic,Hpricot and ruby-prof uses C extensions, either because of performance or because of the ready existing libs related matters.
Well that was causing problems for JRuby users as they couldn’t run those gems that have C extensions, and also for gem developers who had to maintain 2 versions of such gems to let them work for both MRI and JRuby.
That was a kind of disaster till Charles announced that FFI is available for ruby.
So now when you need to have C code inside ruby, then it’s highly recommended to use the FFI gem to save yourself having dual code, and also to make your code work on different ruby implementations.

Make use of the JVM (HotSpot)

Since Sun has announced it’s open source strategy, and lots of optimization work was done for the JVM(HotSpot), the reason behind these optimizations was the fact that many languages is adopting Java to be the hosting language for them, and thus having JVM as an open source technology helped to optimize it to better serve these languages. Some of these languages are: JRuby, Groovy, Scala and Clojure.
So you might be wondering “How this will affect me?”, actually it will affect you indirectly cause once you have a better JVM, it means you have a faster JRuby implementation, and a better management for your memory, as the JVM is considered to have the best garbage collector.
Also you might be able one day to work with other languages(Clojure for example) directly in your ruby code.

Have a great community and support

JRuby has a very nice community, and the guys behind it are very helpful and open to different opinions, just log to #JRuby channel on the FreeNode on IRC, or subscribe to mailing list and send your questions, and you will get the minimum support to let you go.
What i like about this community is their love to the Ruby community, they like to help any rubiest, they even worked with Merb(merb 2 is the core of Rails 3) guys to provide a better performance for merb users.
The current active JRuby contributers are: Charles Nutter, Tom Enebo, Wayne Meissner, Marcin Mielzynski and Nick Sieger, and here some of the past contributers: Ola Bini and Vladimir Sizikov

I hope that i could deliver some of the good points about JRuby, and would like really to have your comments, and what might be also missing from those points. You can find bellow a list of references.

References

*JRuby: What, Why, How…Try It Now by Charles Nutter and Tom Enebo

*JRuby: The Pain of Bringing an Off-Platform Dynamic Language to the JVM by Charles Nutter

*Charles Nutter blog

Update 1
The snippet of code was updated as a respond to Collin’s note

32 Replies to “The power of JRuby”

  1. Yea, JRuby is pretty cool. Here is one project I’m using for GUI development, called Glimmer, it leverages the SWT library, which is superior to Swing, because it uses native widgets.

  2. Although JRuby is emerging as the best Ruby implementation, I feel that Groovy, even in its current youthful form, is a better choice for Java programmers. It offers most of Ruby’s useful features and elegance, but does not require a Java programmer to learn an entirely new library for things like strings, streams, threads, etc, etc. Groovy is a Javatized clone of Ruby.

    I started using Ruby about 5 years ago and would still be using it had Groovy not come along. Ruby is beautiful. I’m grateful to all the Java programmers who agree and who helped bring about the creation of Groovy.

    But Ruby, after these five years has not improved much at all, UTF-8 and multi-threading are still a mess. Few major open source projects have moved as slowly as Ruby 1.9, which is just a stepping stone to the even more vaporous Ruby 2.0. For some reason, the Ruby community is just unable to improve Ruby at a reasonable rate. It reminds me a lot of Perl 6, which has been promised forever but never appears.

    My intuition is that Ruby is a mess internally and because of this very hard to refactor and improve. Problems like this usually require a complete rewrite of the language implementation. Ruby has had plenty of time to do this, but hasn’t. I don’t think the community is capable of it:-( Even if they delivered a solid Ruby 1.9 this year. It would probably taken another 5 years to get to Ruby 2.0. That’s just not gonna cut it.

    Nevertheless, Ruby remains a rich source of excellent ideas. Ruby’s beauty, elegance, and funness have swept through the Java community with great results. I am soooooooo grateful to the Ruby community and Matz for this. Ruby has helped slow Java’s descent into becoming a funless language (such as C++).

    If you’re a Java programmer looking for a productive scripting language, I believe Groovy is your best bet.

  3. I’m not sure why Groovy users feel it necessary to comment on every blog post where someone on the Java platform loves using JRuby. Guys, seriously, you don’t need to chase JRuby users from one end of the world to the other trying to convert them. The Java platform is big enough for both languages to thrive, and both languages take a different approach to integrating with Java. Groovy’s going to be good for some tasks and Ruby will be good for others. Some people will like Ruby and some people will like Groovy or Python or Scala or Clojure or what have you. There is no “best bet” for scripting on the Java platform. Can’t you just leave people alone that like JRuby?

    devdanke: Yes, the standard Ruby implementation has issues, but JRuby solves almost all of them. We’re much faster, parallel-threaded, and obviously have access to many more libraries. Judging Ruby based on the C implementations is myopic at best…JRuby is very real and in many ways much better than those implementations. And we’re continuing to improve how JRuby integrates with the rest of the Java platform. For the most part, the only major piece missing is being able to precompile Ruby code and reference it directly from Java, which is simply complicated by Ruby not having static type declarations like Java and Groovy do. This also opens up a lot of possibilities for Ruby code, since the type system is more fluid from the start. If you haven’t tried JRuby, you really should; it integrates extremely well with Java today and will continue to improve. And almost all your concerns about the standard impls are not issues with JRuby.

  4. Charles I don’t think you’re being fair to “devdanke”. He is obviously a Ruby fan and has read this article out of genuine interest – I find it very hard to believe he is scouring the web chasing JRuby fans as you put it.

    His main point is unchallengable. Groovy is much closer to Java and easier for Java developers to migrate to.

    It is a no-brainer. If you come from Java already, Groovy is the most sensible choice for a dynamic language on the JVM. It has no significant integration issues with Java at all.

    People in established Java shops are suspicious enough as it is of dynamic languages. Its hard enough to get them to try Groovy. Trying to get them to learn Ruby instead is… not something I personally would spend any time on even if I was a Ruby fan myself.

    JRuby seems to be excellent for what it is – a way for Ruby coders to get onto the JVM and leverage the Ruby community’s tools and libraries.

  5. Hi Charles, Groovy is very well known in my customer base (Java shops in Brisbane) but I also bump into people occasionally who haven’t heard of it or other JVM languages apart from Java for that matter. It seems to make sense to let people know about their options. All of them of course including Groovy and others. You would be crazy not to look what is on offer from all the JVM languages but by the same token you would be doing yourself an injustice if you are a Java developers and you didn’t look at Groovy.

  6. Marc Palmer: I don’t think devdanke’s main point is unchallengeable at all. Sure, Ruby is a bit more different from Java, but idiomatic Groovy code that takes advantage of all Groovy’s features ends up looking almost identical to Ruby. So as a stepping stone, Groovy holds a Java developer’s hand more, but the feature set is almost as weird and wild as Ruby. Ultimately, though, this is a pointless debate; many people love Ruby specifically because it’s *not* like Java, and many people are interested in Ruby’s culture, Ruby’s ecosystem, and Ruby itself simply because it suits them better. Groovy being “closer to Java” is a detriment in as many ways as it is a benefit.

    And Ruby is not just “a way for Ruby coders to get onto the JVM”. JRuby is a real, viable JVM scripting language in its own right, and we get as many users coming to JRuby from the Java world as we get from the Ruby world. Yes, many of our users have never used Java before, but many others are new to Ruby. And that’s partially why we’ve stayed true to Ruby but also incorporated JVM and Java features where appropriate: we live in both worlds, and need to balance the needs of each.

    Paul King: This was never a post trying to convert anyone or win users away from other JVM languages. Khaled was obviously just spelling out reasons why he likes JRuby, especially in preference to the C implementations. I find it extremely rude to hijack his post to beat the Groovy drum. Yes, Groovy is great, wonderful, amazing, spectacular…but why say so here? Why try to co-opt Khaled’s enthusiasm to push Groovy? Khaled likes JRuby. Let him like JRuby without evangelising Groovy in comments on his post.

  7. JRuby it’s fantastic, I can deploy and sells Rails application to the “Enterprise” world…no more Struts, no more Seam…
    Headius go on, JRuby it’s awesome! ๐Ÿ™‚

  8. Well, i have tried groovy in my turn also.
    I have found it weird to be in need to use the keyword ‘static’ to define static methods and variables when it comes to a dynamic language.
    I have found it weird to be in need to use the keyword ‘def’ to declare variables.
    Everything else is about Java, if you are a Java developer then you can use the Java syntax directly inside your groovy code, and most of the guys are doing so, which is in my opinion is nothing but a way to escape the static typed Java to ‘somehow’ a dynamic one.

  9. Hi khelll, not going to step back into the flame war but just to clarify on Groovy syntax.

    The ‘static‘ keyword in Groovy is the same as in Java, i.e. an OO structuring concept to allow for methods/fields which are shared amongst all objects of that type. Think ‘@@’ class variables perhaps. Not really anything about dynamic/static typing.

    Using the ‘def‘ keyword is related to dynamic typing. It indicates that the type will be determined at runtime. Conceptually not much different from saying Object and you can leave it out at the global level in script if you wish. Much as Ruby uses ‘def’ to introduce method definitions, Groovy uses ‘def’ to introduce variable declarations and method definitions – unless you want to use a specific variable type/method return type in which case you can – again Java heritage showing through here.

  10. As much I”m so excited about JRuby efforts and what did they achieve in a very short period .. as much as I’m so disappointed for the following reasons:

    1- Ruby has now so many different implementations, IronRuby, JRuby, Ruby itself .. etc, among all these implementations, and after looking at so many benchmarks measuring their performance levels, There is no official reference (Yes, Ruby engine itself is being used as the main reference implementation) that can define the API standards that every one MUST follow. Every single implementation has its own weak points, not ALL apis are supported, some of them are still buggy.

    Imagine, those guys are developing Rails, still need to add more effort to even create different implementations for different ruby engines .. same what happened to Rails 2.2 when they added (finally) support for JRuby, and yet it’s not there for production.

    2- Assuming the JRuby is the only closest implementations, YET, it doesn’t support using native libraries for some plugins such as RMagick .. Ruby can directly access native libraries, but JRuby requires only ruby-based or Java based libraries .. I’m not sure if they could add JNI support!

  11. JRuby does indeed rock. Happy Camper Studios (I’m a co-owner) use it to build commercial desktop applications, such as JotBot. It was built using the Monkeybars library which, thanks to JRuby, is the easiest, most powerful way to make desktop apps in Ruby.

  12. Any plans for JRuby support of the win32ole ruby core class?
    Groovy has com scripting.
    It would be nice to see the com library supported.

  13. @devdanke

    Perl 6 is brought up quite frequently as some sort of archetypal example of vapourware. This however is completely absurd. Comparing the development of Perl 6 to Ruby 1.9 is like comparing Linux development to the development of GNU/Hurd. There is a large team of people working very hard to get Parrot to 1.0 so it can host Rakudo (Perl 6 on Parrot; Perl 6 is a language specification, not an implementation itself; In that sense Perl 6 has been basically “done” for a while ;). It has taken years and years, but Parrot is emerging as an extremely well-designed VM built from the ground up for dynamic languages. Whereas YARV was basically designed by one person and implemented by a very small team.

    Perl 6 is not vapourware, just as Python 3000 wasn’t. It just takes time to do things right, and Perl 6 (via Parrot) had it in mind to first develop a VM that would allow any dynamic language could basically implement itself, in itself, after developing a bootstrapped version of that language. Perl 6 is being written in NQP which is a pared down version of the language that uses the same syntax. Granted it has taken a while to get there, but few people in the future are going to argue that it was time wasted.

    The Ruby community is seemingly obsessed with hating Perl, possibly leading the Rubinius team to decide that somehow they could write a whole new VM to “write Ruby in Ruby” when in fact Parrot is ideally suited for this choice and would allow an insane level of expandability to Ruby (anything Perl 6 can do, any language implemented on Parrot can do, and P6 can do _a lot_). I can’t speak for their decisions, and I think they do great work, I just think it was a huge act of hubris to decide that writing a brand new VM with such a small team would result in something more capable than Parrot at running a Ruby written in Ruby.

  14. @ Ibrahim Salem, 1-Rails is working very well for JRuby in non threaded mode. You MIGHT have some problems in threaded mode with SOME gems or plugins which don’t support threading the right way (and yes there are some of them), but this is should be solved in the near future and it’s not a problem of JRuby anyway . 2-That’s why it’s highly recommended to use the FFI to wrap C extensions instead of the old way, and thus the code will work for most of the implementations including JRuby, also an example is the Syslogger gem which is using the FFI right now and works well for Ruby MRI and JRuby.

  15. As a Java/Swing guy I have to ask this. What thread is your example running on and why do you need the Thread.stop? Swing components should always be created and modified on the ‘event dispatch thread’. The EDT runs even if the main thread completes so you don’t have to play an tricks to keep your JVM running. Also you tend to tell a single framed application to “exit on close” so that the app exits when you click the close button on the window frame. Is there something ins special in JRuby that takes care of some of these things?

  16. Sorry, my previous post probably needs a little clarification. It was certainly off topic (apologies) but it is not entirely disconnected. Let me explain:

    JRuby, despite being the fastest implementation and the most sensible deployment platform for a web app (assuming your app is multithreaded there is no contest) it has this stigma of being second class in some way. Or a trojan horse. Headius has already written about this in the elephant. This reputation is not deserved. JRuby will not kill Ruby, or destroy the community.

    And neither is the canonization of Perl 6 as the Prime Vapor. People have been putting a lot of work into a system designed from the ground up to be both expansive and inclusive. When Parrot 1.0 is out and high level language development truly stabilizes it will be the best platform for writing Ruby 2.0. Matz could literally cherrypick from the Perl 6 featureset, do his magicawesome-syntax-fu on those enhancements, and voila Ruby 2.0 takes less than a year (after the date 1.9 is implemented). That said, Parrot 1.0 isn’t here yet so I can (sort of) understand why neither Matz nor the Rubinius team chose it.

    My point is: stop using Perl 6 as the language that never made it. It is coming, it will be here, and once it is, a lot of things will change. And everyone who loves dynamic languages is going to cream themselves when they realize what we’re getting in Parrot. Sorry to jack the thread, I just see this meme so often and today devdanke’s comment was the final straw. Apologies for the bizarre rant but they say venting is healthy, right?

    Viva la Ruby!

  17. Greetings,

    Good article; a nice overview of some of the benefits. Too bad it got hijacked. ๐Ÿ™

    I found JRuby to be very useful to embed in an application to provide scripting support. Because of the ease of building simple DSLs in Ruby, I can provide a scripting interface that non-programmer users can basically understand, but that calls down into the apps original Java code.

    It adds about 8MB to app download (after stripping rspec, rake and gems out), and startup is a little slow, but with some judicious threading, that can be hidden in other startup times.

    I’m really happy with how JRuby has come along.

    — Morgan

  18. @jason

    Ruby 1.9 (or to be more specific the YARV implementation of it) will allow compilation to bytecode as far as I know. But this will be a JIT (just-in-time) compiler, so you will still distribute the source-code, and the virtual machine will optimize it to bytecode when running a piece of code for the first time. Pre-compilation of Ruby-code is not an easy task (or nearly impossible), as Ruby is very dynamic and allows changing all it’s code during runtime. Please correct me anyone if I’m wrong here.

  19. Hello Charles Oliver Nutter,

    It is an honor to have you comment on my post. You and your compatriots have done an excellent job with JRuby. In my opinion, your work is a model of efficient, effective open source development. I am grateful to the JRuby team.

    You are correct, there is room on the JVM for JRuby, Groovy, and other languages.

    I apologize if it seemed like I was trying to scare people away from J/Ruby. I was just offering my opinion, based on my experience, to Java devs who hadn’t tried either language yet. It’s it only with reluctance that I made my suggestion, because I really do appreciate the beauty of Ruby.

    I haven’t tried JRuby since 1.1. I’ll take your advice and try it again, especially to see how it integrates with existing Java libraries.

    -devdanke

  20. This page seems to recieve a large ammount of visitors. How do you get traffic to it? It offers a nice unique twist on things. I guess having something useful or substantial to talk about is the most important factor.

  21. Cliff, I think escapist hindi cinema does a far greater service to the wretched Indian masses than say Manjha or SDM ever couldit lifts them out of their misery for three glorious hours..which is why SRK and AB are icons today, and funnily enough the actuals slumdog kids would anyday rather go see Rab Ne or Dostana than Gulaal or SDM!.Truth is that the niche segment of the population that actually watches indie films is not affected by the issues being portrayed onscreen..that is the greatest irony.A case in point..popular tv series Balika Vadhu that sheds light on social evils against child-women in rural India, is mostly watched my middle-upper middle class housewives who have never had to experience the horrors of the dust caked interiors..A social worker who works with actual victims of the crimes that are portrayed on BV said to me that she really wished they had access, time or permission to watch those shows..you think these fat, bored obtuse behenjis sitting in their Lokhanwala or Greater Kailash living rooms are moved enough to actually do anything about it? No Way. Which is why your argument that movies can enlighten people and make a difference in the areas they shed light does not hold weight at all..

  22. Great ยกV I should definitely pronounce, impressed with your web site. I had no trouble navigating through all tabs as well as related info ended up being truly simple to do to access. I recently found what I hoped for before you know it at all. Quite unusual. Is likely to appreciate it for those who add forums or anything, website theme . a tones way for your customer to communicate. Excellent task..

  23. I have just installed JRuby and have an irb prompt:

    irb(main):033:0>

    I am working in a text that wants me to write a program called example.rb and then run it from a $ prompt like this:

    $ jruby example.rb

    How do I get to the “$” prompt from the irb prompt?

  24. 。私は間違いなくあなたが言っていたものを楽しみました。あなたは間違いなく、このトピックに新しい音声をもたらすので、続けます。ない多くの人々はホードが言ったことを言うとまだそれは興味深いものになります。素敵な、少なくともイム興味。あなたからのこの多くの詳細を参照するのを待つ傾けます。

Leave a Reply

Your email address will not be published. Required fields are marked *