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:
# Import Java packages
include Java
import javax.swing.JFrame
frame = JFrame.new("Hello Swing")
button = javax.swing.JButton.new("Klick Me!")
button.add_action_listener do |evt|
javax.swing.JOptionPane.showMessageDialog(nil, <<EOS)
<html>Hello from <b><u>JRuby</u></b>.<br />
Button '#{evt.getActionCommand()}' clicked.
EOS
end
# Add the button to the frame
frame.get_content_pane.add(button)
# Show frame
frame.set_default_close_operation(JFrame::EXIT_ON_CLOSE)
frame.pack
frame.visible = true
</html>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