JRuby: When Ruby Meets the Java Virtual Machine

If you have worked with Ruby, you probably know the usual way Ruby applications run: install Ruby, write some Ruby code, and execute it using the standard Ruby interpreter.

But Ruby has another interesting option that does not always get much attention: JRuby.

JRuby lets you write Ruby code while running it on the Java Virtual Machine (JVM).

At first, that may sound like an unusual combination. Ruby and Java have very different programming styles, ecosystems, and histories. But bringing Ruby to the JVM creates some useful possibilities, especially for organizations that already have a significant investment in Java.

In this article, I want to explain JRuby from a practical point of view: what it is, how it works, why someone would use it, and when it may or may not be the right choice.

First, What Exactly Is JRuby?

JRuby is an implementation of the Ruby programming language that runs on the JVM.

Normally, when we talk about Ruby, we are usually talking about CRuby, also known historically as MRI (Matz's Ruby Interpreter). It is the standard and most widely used Ruby implementation.

With JRuby, the language is still Ruby.

You still write code like this:

class Greeting
  def initialize(name)
    @name = name
  end

  def say_hello
    puts "Hello, #{@name}!"
  end
end

Greeting.new("JRuby").say_hello

The difference is underneath.

Instead of executing the application through the standard Ruby runtime, JRuby executes Ruby code using the JVM.

A simplified way to think about it is:

Traditional Ruby

Ruby Application
      |
      v
   CRuby
      |
      v
Operating System


JRuby

Ruby Application
      |
      v
    JRuby
      |
      v
     JVM
      |
      v
Operating System

The Ruby developer can continue thinking and programming largely in Ruby, while the application gets access to capabilities of the Java platform.

That last part is where JRuby becomes interesting.

Why Would We Run Ruby on the JVM?

My first reaction when looking at technologies like JRuby is usually:

What problem are we actually solving?

Running Ruby on the JVM just because we can is not particularly useful. There needs to be a reason.

One of the strongest reasons is Java interoperability.

Imagine an organization that already has years of investment in Java. It may have internal Java libraries, enterprise frameworks, database drivers, security components, messaging infrastructure, or proprietary SDKs.

Now suppose a team wants to build part of an application using Ruby.

Without JRuby, the boundary between those two environments can require APIs, services, queues, or some other integration mechanism.

JRuby provides another option.

Ruby code can interact directly with Java classes.

For example:

java_import java.util.ArrayList

languages = ArrayList.new

languages.add("Ruby")
languages.add("Java")
languages.add("JRuby")

puts languages

This is Ruby code creating and using Java's ArrayList.

That is a simple example, but the same idea can become much more powerful with real Java libraries.

Ruby on Top, Java Underneath

One way I like to think about JRuby is that it gives us two worlds at the same time.

At the application level, developers can use Ruby's expressive syntax:

customers.each do |customer|
  process(customer) if customer.active?
end

At the platform level, the application can take advantage of the JVM and the enormous Java ecosystem.

Conceptually:

        Ruby Application
              |
              v
        +-------------+
        |    JRuby    |
        +-------------+
          /         \
         /           \
        v             v
 Ruby Libraries    Java Libraries
         \           /
          \         /
           v       v
              JVM

This is probably the most important idea to understand about JRuby.

It is not a new programming language. It is another implementation of Ruby, with the JVM underneath it.

Calling Java from Ruby

Let's look at another small example.

Java provides the System class. From JRuby, we can access it directly:

java_import java.lang.System

puts System.getProperty("java.version")
puts System.getProperty("os.name")

We can also use Java libraries for functionality that may not normally be part of a Ruby application.

For example:

java_import java.util.UUID

id = UUID.randomUUID

puts "Generated ID: #{id}"

The code still feels like Ruby, but the UUID implementation comes directly from Java.

For a small demo this may not seem important.

In a large enterprise environment, however, imagine replacing UUID with an internal Java library that handles authentication, encryption, payments, messaging, or access to a proprietary system.

Now the value becomes easier to see.

What About Ruby Gems?

JRuby also supports the Ruby ecosystem and RubyGems.

For many libraries, the experience is similar to standard Ruby:

gem install bundler

And then:

bundle install

This means a JRuby application can potentially use both:

• Ruby gems
• Java libraries

That combination is one of JRuby's biggest strengths.

There is an important caveat, though.

Not every Ruby gem is automatically compatible with JRuby.

Pure Ruby gems generally have a much easier path. Gems that depend on native C extensions can be more complicated because JRuby is running on the JVM rather than using CRuby's native extension model.

So if I were evaluating an existing Ruby application for JRuby, dependency compatibility would be one of the first things I would check.

JRuby and Concurrency

There is another reason JRuby has historically been interesting for server-side applications: concurrency.

CRuby uses a mechanism commonly called the Global VM Lock (GVL). It affects how Ruby threads execute Ruby code concurrently within a process.

JRuby runs on the JVM and can use JVM threads without CRuby's GVL.

In simplified terms:

JRuby Thread 1 ----\
JRuby Thread 2 -----+----> JVM Threads ----> CPU Cores
JRuby Thread 3 -----+
JRuby Thread 4 ----/

This can make JRuby attractive for certain multithreaded workloads.

That does not mean that moving an application from CRuby to JRuby automatically makes it faster.

Performance depends on the workload, libraries, JVM configuration, memory behavior, application architecture, warm-up characteristics, and many other factors.

"JRuby is faster than Ruby" is therefore too broad a statement.

A better way to say it is:

JRuby has a different runtime and concurrency model, which can be advantageous for certain workloads.

Benchmark your actual application rather than making the decision from a generic benchmark.

Can Rails Run on JRuby?

Yes.

JRuby has long supported Ruby frameworks such as Ruby on Rails, and a Rails application can run on JRuby.

Conceptually, the architecture looks something like this:

Browser / API Client
        |
        v
   Rails Application
        |
        v
      JRuby
        |
        v
       JVM
        |
   +----+-----+
   |          |
Ruby Gems  Java Libraries

Why would anyone do this instead of running Rails on standard Ruby?

Again, context matters.

If an organization is primarily a Java shop but has an existing Rails application, JRuby can sometimes provide a bridge between those environments.

The Rails team can continue working with Ruby while gaining access to JVM-based infrastructure and Java libraries.

A Practical Enterprise Scenario

Consider a company with this environment:

Existing Enterprise Platform
        |
        +-- Java authentication libraries
        |
        +-- Java messaging libraries
        |
        +-- Internal Java SDKs
        |
        +-- Existing JVM monitoring
        |
        +-- Ruby / Rails application

One option is to rewrite the Ruby application in Java.

That could be expensive and risky.

Another option is to keep Ruby and expose every Java capability through network APIs.

That may be the correct architecture, but it also introduces additional services, network calls, deployment units, and operational complexity.

A third option worth evaluating is JRuby.

Ruby / Rails Application
          |
        JRuby
          |
          JVM
       /   |   \
      /    |    \
 Auth   Messaging   Internal SDK
 Java     Java         Java

This does not mean JRuby should always be selected.

It simply gives architects another option.

And in software architecture, having another reasonable option can be valuable.

Where JRuby Makes Sense

I would seriously consider JRuby when several of these conditions exist:

• The organization already has a large Java ecosystem. If important business functionality already exists in Java libraries, JRuby can provide direct access without requiring everything to be rewritten.
• The development team prefers Ruby. A team may be highly productive with Ruby and Rails while the broader organization standardizes around JVM infrastructure. JRuby can help connect those worlds.
• The application has significant multithreading requirements. JRuby's JVM threading model may be useful for workloads where true parallel thread execution matters.
• Existing JVM operational tooling is important. Organizations often have mature JVM monitoring, profiling, deployment, and operational practices. Running Ruby on the JVM may fit better into that environment.
• Rewriting an existing Ruby application would create unnecessary risk. Sometimes modernization does not require rewriting everything. A runtime change or integration strategy can be a more practical engineering decision.

Where JRuby May Not Be the Best Choice

JRuby also introduces tradeoffs.

• If you are building a normal Rails application with no need for Java integration, standard Ruby may be simpler.
• If your application depends heavily on gems containing native C extensions, migration can require additional investigation or alternative libraries.
• The JVM has its own operational characteristics, including memory configuration, garbage collection, startup behavior, and performance tuning.
• Your team needs to understand another layer of the technology stack.

Ruby
  +
JRuby
  +
JVM

Every additional layer creates both capabilities and operational responsibility.

That is why I would not choose JRuby simply because it sounds technically interesting.

There should be a clear reason.

JRuby Is Also an Interesting Architecture Lesson

What I find most interesting about JRuby is not just the technology itself.

It is the architectural idea behind it.

We often think of programming languages and runtime platforms as a single package:

Ruby -> Ruby Runtime

Java -> JVM

C# -> .NET

JRuby reminds us that the language we write and the runtime executing that language do not necessarily have to be the same thing.

A programming language is one layer.

The runtime is another.

The libraries are another.

The operating environment is another.

Once we separate those ideas, technology choices become more interesting.

Instead of asking:

Should we use Ruby or Java?

Sometimes the better question is:

Which language makes our developers productive, and which runtime gives the application the capabilities it needs?

JRuby is one possible answer to that question.

Final Thoughts

JRuby is not a replacement for Java, and it is not necessarily a replacement for standard Ruby.

It sits somewhere between those two ecosystems.

It allows developers to keep Ruby's expressive programming model while taking advantage of the JVM and Java libraries.

For a new application with no Java dependencies, I would probably start with standard Ruby unless there was a specific reason not to.

But for an enterprise environment with substantial Java investments, an existing Ruby application, or specific concurrency requirements, JRuby becomes much more interesting.

And that is probably the simplest way to understand it:

JRuby lets you write Ruby without giving up the Java ecosystem underneath it.

Sometimes that combination solves a problem that neither ecosystem solves as conveniently on its own.