Over a million developers have joined DZone.

The Future of JRuby with Thomas Enebo - Core JRuby Developer

DZone's Guide to

The Future of JRuby with Thomas Enebo - Core JRuby Developer

· Java Zone
Free Resource

Build vs Buy a Data Quality Solution: Which is Best for You? Gain insights on a hybrid approach. Download white paper now!

[img_assist|nid=3197|title=|desc=|link=none|align=right|width=80|height=100]JRuby is by far the most popular Java implementation of the Ruby programming language. The 1.1.2 version has just been released with improvements in startup time, performance and threading. Thomas Enebo, one of the main JRuby developers, recently talked to me about the popularity of the language, the JRuby project, and when it's right to use Ruby over Java.

James Sugrue: For those of us who aren't familiar, can you give a quick overview of Ruby?

Thomas Enebo: Ruby is a pure object-oriented dynamically-typed programming language. It was written around feeling natural and fun to the programmer as opposed to being written to be productive (or substitute with another industry term). As a result, it is a beautiful, productive language that seems to make a fan out of most people who try it.

Ruby has a comprehensive set of libraries which come in a Ruby distribution (like JRuby). This is similar to Java in that you can expect a decent selection of APIs which you know will be in any Ruby installation. Additional libraries are installed by a simple packaging facility known as ruby gems. You are just one command away from having the new library you want (and no classpath nightmares).

Ruby has largely been popularized by the Ruby on Rails full-stack web framework. Ruby itself started as a language in 1993 whereas Ruby on Rails was started in 2004. Rails is currently the "killer app" of Ruby and it is helping to attract lots of new Rubyists. People wanting an overview of Rails should go to http://www.rubyonrails.org/.

Sugrue: What are the major changes since JRuby1.0?

Enebo: JRuby 1.1 was largely focused on performance. JRuby 1.0 had a partial compiler and JRuby 1.1 ended up havng a full compiler which works in AOT or JIT modes. The compiler is a boon for performance. Beyond the compiler we went over most of our standard libraries, from Array to Zlib, and tuned them to be faster.

During this time we also fixed thousands of compatibility issues. Our confidence in Ruby compatibility is at an all time high. People can run their app written against the C implementation of Ruby and it just works in JRuby.

Sugrue: What's coming up in the next few months for JRuby?

Enebo: The next big task is rewriting/refactoring our Java Integration (JI) support. JI is our ability to talk to Java classes from within Ruby. JI works well enough for anything I have done with it and I think most people are happy with it, but we have lots of issues filed for more obscure corner cases. The implementation is also messy. We need to go back through and clean things up much in the same way we did for our other subsystems while developing JRuby 1.1.

We also are on a never ending quest to improve performance. Expect continued improvement in speed as the year progresses.

And bugs... :)

Sugrue: What are the biggest challenges you've come across while writing JRuby?

Enebo: A huge issue with implementing an alternate Ruby implementation is that the Ruby specification is the C implementation. There is no formal specification for the language or core libraries. This involves developing lots and lots of tests. It also involves picking up a library that doesn't work and then just hack away until it does. After years of development we have conquered this area, but it has been a painful process.

This has also been my first time I worked on a language implementation. Picking stuff up and learning on the way is fun, but also challenging since it may mean that you end up changing the implementation of some piece every time you learn something new.

Sugrue: When is it the right move to go from Java to Ruby? What use cases does Ruby have the edge?

Enebo: I think these can be difficult questions to answer. I program in Java and Ruby daily and I am sometimes not sure which one I will pick. I will say it is difficult to beat Java in terms of speed in an apples to apples comparison. OTOH, Ruby is much more expressive so you can probably make a more sophisticated solution to beat Java in an apples to oranges comparison. Ruby feels more light weight in terms of restrictions it puts on you as a programmer. I can write something in a fraction of the number of lines in Ruby that I can in Java. I also believe it can be more readable. OTOH, Java's static typing allows another degree of sophistication in its tooling support; so things like refactoring are pretty simple in Java. So having a larger less readable solution is not as much of a detriment.

Basically, I would recommend people try the language out and see how they like Ruby as a language. I love the language and would not be spending so much time working on a Java implementation of it if I didn't (so I am biased).

Sugrue: Is the future bright for Ruby?

Enebo: YES! Seriously, it is a fantastic language that is good for much more than writing just web applications with. With that said, I believe Ruby on Rails will be the largest driving force for programmers learning Ruby for time being. For people who bothered to read this all....Ruby is a tremendously powerful language with a decent set of APIs. You DO NOT need to learn Rails to be able to use Ruby. Here is a snippet of an image manipulation library for JRuby (which is only 200 lines of Ruby+Java2d called image_voodoo [actually probably less than 60 lines makes up what this example does]):

require 'image_voodoo'

file = ARGV[0]
ImageVoodoo.with_image(file) do |image|
image.cropped_thumbnail(100) { |img2| img2.save "#{file}_cropped.jpg" }
image.resize(100, 150) do |img2|
img2.save "#{file}.jpg"
img2.save "#{file}.png"

I am sure everyone can read this code without ever seeing Ruby. Can you also imagine writing something as powerful as expressive as this library in 60 lines of Java?

Build vs Buy a Data Quality Solution: Which is Best for You? Maintaining high quality data is essential for operational efficiency, meaningful analytics and good long-term customer relationships. But, when dealing with multiple sources of data, data quality becomes complex, so you need to know when you should build a custom data quality tools effort over canned solutions. Download our whitepaper for more insights into a hybrid approach.


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}