My JRuby Saga: Or How I Learned to Stop Worrying and (Almost) Accept the JVM

Recently, I found myself upgrading some foundational gems—the kind used by thousands of other packages. That means millions of indirect users. It’s the software equivalent of performing heart surgery while git push --force runs in the background. One bad 2 AM commit, and someone’s production cluster gets an unexpected nap.

That’s when I discovered that the gem with_advisory_lock supports JRuby.

Now, JRuby and I have a long-standing… disagreement. It runs on a platform I’ve never trusted—named after caffeine and volcanoes. You know, things that keep you up all night and occasionally explode without warning.

Why the JVM Never Sat Right

My problem with Java has never just been about the language. It’s the mentality: that corporate mindset where backward compatibility is preserved like ancient fossils. Last time I looked, JRuby was still running on Java 8. Yes, Java 8. That’s the one that Moses probably installed on his tablet at Sinai.

For a platform that releases every six months, why was it still depending on a version from the prehistoric software era?

JRuby 10 and Rails 8: A Surprising New Pairing

Then it happened—@headius announced: JRuby 10 is officially released, and it now requires Java 21 at minimum.

Even better: I’m now working directly with the JRuby team to update activerecord-jdbc-adapter to support Rails 8 on JRuby 10.

And that’s a big deal. It means modern Rails apps can finally run on JRuby without dragging two decades of compatibility hacks along for the ride. I get to start sweeping out all the dusty conditional logic, monkey patches, and shims that were only there for ancient Rails versions.

It’s janitor work—but deeply satisfying janitor work.

Why I’m (Reluctantly) Impressed

Here’s the thing: the JRuby workflow is refreshingly human. Fix a spec, send a PR, get feedback, get merged. Fast. No endless waiting, no philosophical debates about whether your commit aligns with the phase of the moon. Just forward momentum.

Compare that to other ecosystems where you work for a week to turn the build green, and the maintainers reply: “Oh, we rewrote everything yesterday. Closing your PR—cheers.”

The Modern JVM Isn’t Your Father’s Enterprise Monster

Working with JRuby 10 has been… surprisingly pleasant. The startup times that used to make you grab a coffee are now just a brief pause. The memory footprint that once required dedicated servers now fits comfortably in a container. And the performance? Well, let’s just say it’s not embarrassing anymore.

The JVM has grown up. Java 21 brings:

• Project Loom: Virtual threads that make concurrent Ruby code actually work
• Modern GC: ZGC and Shenandoah that don’t pause your app for geological time periods
• Better tooling: Profiling and debugging that doesn’t feel like archaeology

The Rails 8 Integration Challenge

Getting Rails 8 working on JRuby 10 means diving deep into the JDBC adapter—the bridge between Ruby’s ActiveRecord and Java’s database drivers. It’s like being a translator between two stubborn relatives who refuse to speak the same language.

Rails 8 introduced some breaking changes that made the old adapter throw tantrums. New connection handling, updated SQL generation, and modern Ruby features that the adapter had never seen before. Each spec failure was a mini-mystery: “Is this a Rails change, a JRuby issue, or just cosmic rays flipping bits?”

But here’s the satisfying part: every fix makes the ecosystem stronger. When you patch the JDBC adapter, you’re not just fixing one app—you’re fixing it for everyone who’ll ever run Rails on JRuby.

A Grudging Appreciation

So this post is mostly a thank-you to the two people who’ve kept JRuby alive and evolving:

Charles Nutter (@headius) and Thomas E. Enebo (@enebo).

Thanks for making JRuby 10 happen. You’ve brought Ruby on the JVM into the modern age. You’ve proven that corporate platforms can evolve beyond their enterprise legacy. And somehow, despite myself, I’m glad to be part of it.

Would I choose the JVM for a greenfield Ruby project? Probably not. But would I yank JRuby support from existing gems out of spite? Also no.

Progress isn’t always about picking the perfect tool. Sometimes it’s about making the tools we have work better together.

---

P.S. - If you’re maintaining gems that claim JRuby support, please test them on JRuby 10. Your future self (and everyone else’s production environment) will thank you.