JRuby & Rails Compatibility Table
This is a short post to show the compatibility between JRuby and Ruby on Rails across different versions. JRuby is an implementation of Ruby that runs on the JVM, so picking a version means lining up four things at once:
- JRuby release
- Ruby version
- Minimum Java version
- Rails version
JRuby tracks a specific CRuby (MRI) language level per release, and Rails support on JRuby is delivered through the activerecord-jdbc-adapter gem, whose version number mirrors the Rails version it targets. The Rails versions listed below are the ones that both run on that JRuby line’s Ruby language level and have a matching adapter release.
| JRuby Version | Ruby Compatibility | Minimum Java Version | Compatible Rails Versions | Status |
| 10.1.Z | 4.0 | >= 21 | 7.1, 7.2 (*) Rails 8.0 runs on JRuby 10's Ruby language level, but the adapter for it (activerecord-jdbc-adapter 80.x ) is still under active development. Pre-release (pre1) versions are already available and may work just fine for your app. | Latest release; the JRuby team recommends staying on 10.0 for production while 10.1 stabilizes |
| 10.0.Z | 3.4 | >= 21 | 7.1, 7.2 (*) Rails 8.0 runs on JRuby 10's Ruby language level, but the adapter for it (activerecord-jdbc-adapter 80.x ) is still under active development. Pre-release (pre1) versions are already available and may work just fine for your app. | Current and recommended for production |
| 9.4.Z | 3.4 | >= 8 | 7.0, 7.1, 7.2 | EOL as of 9.4.15.0 (June 2026); future 9.4.x releases provided only as needed for commercial users |
| 9.3.Z | 2.6 | >= 8 | 6.0, 6.1 (*) The adapter exposes a 70.x line for Rails 7.0, but Rails 7.0 requires Ruby >= 2.7.0 , so Rails 7.0 needs JRuby 9.4 (Ruby 3.1) rather than the 2.6-level 9.3 line. | EOL (no longer supported in OSS) |
| 9.2.Z | 2.5 | >= 8 | 5.2, 6.0, 6.1 | EOL |
| 9.1.Z | 2.3 | >= 7 | 5.0, 5.1, 5.2 | EOL |
| 9.0.Z | 2.2 | >= 7 | 4.2, 5.0 | EOL |
| 1.7.Z | 1.8.7 / 1.9.3 (2.0 mode) | >= 6 | 3.2, 4.x | EOL |
To find more information about the most recent JRuby releases, check out the JRuby news page and the JRuby roadmap .
Running Rails on CRuby (MRI) instead? We keep a companion table for that too: Ruby & Rails Compatibility Table .
A Few Reasons to Run JRuby
If you have only ever run Rails on CRuby (MRI), here are a handful of reasons teams reach for JRuby:
-
Real parallelism: JRuby has no Global VM Lock, so a single multi-threaded process (for example, Puma with a thread pool) can use every CPU core instead of forking a process per core. That often means fewer processes and a smaller memory footprint for concurrent, I/O-heavy workloads.
-
The JVM ecosystem: you get a battle-tested runtime with a mature JIT, mature garbage collectors, JDBC drivers, and observability tooling (JMX, Java Flight Recorder) that you can point at your Rails app without leaving Ruby.
-
Simple packaging: you can bundle a Rails app into a single
.waror.jarand deploy it on the same infrastructure your JVM services already use.
JRuby’s main trade-off has historically been slower startup and JVM warmup. JRuby 10 narrows that gap with features like AppCDS (class data sharing) and Project CRaC checkpointing, but it is still worth measuring against your own workload.
Thinking About Moving from CRuby to JRuby?
Migrating a Rails app from CRuby to JRuby is mostly about getting onto a current, supported Ruby language level, swapping native C extensions for JRuby-friendly alternatives, and switching to the JDBC database adapters. It is the same kind of careful, incremental work we do on Rails upgrades every day.
If you are curious whether JRuby is a good fit for your app, or you want help making the move, we would love to talk. Send us a message over here: Contact FastRuby.io .
Feedback Wanted: Updates
If you find that this article has fallen out of date, feel free to reach out to us on Mastodon or Bluesky and we will bring it up to speed. We will continue to update this article as new versions of JRuby and Rails are released.