JRuby is a real parallel Ruby that also pays rent on the JVM

Concurrency without a global interpreter lock

The About section states the goal in one sentence and then lists the reasons: a complete, correct and fast implementation of Ruby that also provides concurrency without a global interpreter lock, true parallelism, and tight integration with Java in both directions.

Both directions is the part that distinguishes JRuby from a Ruby that merely runs on a virtual machine. Java code can call into Ruby, so an existing Java application can host a scripting layer without a process boundary. Ruby code can call Java classes, so a Ruby program can use a JVM library directly rather than through a bridge, a shim or a subprocess. The README lists the ways people actually use it as a faster Ruby, as Ruby on the JVM with access to tuned concurrency primitives, and as an embedded scripting language in a Java program.

There is no GIL, which means two Ruby threads on two cores are two Ruby threads on two cores. That is the feature that matters for CPU-bound work and the one that makes JRuby a different tool rather than a drop-in substitute. It also means the usual reasoning about Ruby's threading model does not transfer, in either direction.

The repository has 3,919 stars, 950 forks and 944 open issues, with the last push on 2026-09-21. The issue count is high in absolute terms, and for a project of this age and size that is a backlog rather than a crisis, though it does mean filing an issue is not a route to a quick answer.

Three release lines, and the Ruby version decides which

The README's header block shows the branch structure as three CI badges: master and 10.1 on one, then 10.0 and 9.4. That is the whole support matrix, and it maps onto Ruby versions rather than dates.

The release notes state the target explicitly. JRuby 10.1.x targets Ruby 4.0 compatibility, published as 10.1.2.0 on 2026-09-21. JRuby 10.0.x targets Ruby 3.4 compatibility, published as 10.0.7.0 the same day. Publishing two releases within an hour of each other is normal for this project and is the clearest sign that maintenance is active rather than aspirational.

So if you have an application pinned to Ruby 3.4 semantics, you take 10.0.x. If you want the newest language behaviour, you take 10.1.x. Choosing wrongly is not a subtle problem, since the point of a line is that it implements a specific Ruby version.

Getting JRuby installed is where the README spends its practical advice, and the guidance is worth following in order. You need a JRE, version 21 or higher. Your operating system may package JRuby, but the README warns that the packaged version is likely to be very old, which is the reason to use a version manager instead:

$ rbenv install jruby

That lists what is available, and the README notes the list can be out of date if you are not regularly updating rbenv. Then you install the specific version you want:

$ rbenv install jruby-10.0.2.0

rvm and Homebrew both work with a single command each, `rvm install jruby` and `brew install jruby`, and packages can also be downloaded from the project's website and unpacked and run in place.

What the recent releases actually changed

The 10.1.2.0 notes are a good sample of what maintenance on this project looks like in practice, and they are mostly not about new syntax.

On compatibility, there are multiple fixes for fibers and fiber scheduler support across eight referenced issues, which is the kind of work that only shows up as a list of numbers because it is a long tail of small cases. On performance, a regression in startup time on macOS was fixed by properly loading the native JNR subsystem, and performance of Ruby subclasses of Java classes was improved through two changes. The same JNR startup fix appears in the 10.0.7.0 notes, which means it was fixed on both lines.

The autoloads-overridden-by-require improvement appears in both releases too. Two entries stand out in 10.0.7.0 as JVM-facing rather than Ruby-facing: the location of the AppCDS archive file can now be specified with JRUBY_JSA_HOME, which matters if you run on a JDK that supports class data sharing, and the jar-dependencies update moved to mima for dependency resolution in place of the ruby-maven gem. Application class data sharing is a start-up optimisation, so the environment variable is a deployment knob rather than a development one.

10.1.1.0 from 2026-07-22 has a security angle worth naming. jruby-openssl moved to 0.16.2 with several CVE fixes coming through from BouncyCastle, and erb moved to 6.0.1.1 to address CVE-2026-41316. It also switched string-to-double parsing to FastDoubleParser, which affects every float parsed from a string, and added native library backend support for OpenBSD.

That release also begins deprecating jruby-complete. The self-contained jar was the easiest distribution for a long time, and its deprecation is a real change for anyone who relied on it, so it is worth noticing before a future major removes it.

The build is Maven with a Rakefile and a Ruby POM

The tree explains the hybrid build. There is `pom.xml`, a Maven wrapper in `mvnw` and `mvnw.cmd`, a `.mvn/` directory, `pom.rb` and `shaded/`. There is also a `Rakefile`, a `rakelib/` directory and a `Gemfile`. So a Maven project drives the build while the parts of the toolchain written in Ruby are driven by Rake, and the Maven descriptor itself comes from `pom.rb`.

That arrangement is unusual enough to be worth understanding before contributing, and the README handles it by pointing at BUILDING.md for prerequisites, compilation and how to test. That file is in the tree rather than expanded in the README, which is the right division of labour for a build this shape.

The directories tell you where the work lives. `core/` and `lib/` are the implementation, `spec/` holds the specs and `test/` the tests, `bench/` the benchmarks, `tool/` the build tooling, `install/` the packaging, and `samples/` the examples. That samples directory is worth a look as documentation, since a language runtime that can be embedded in a host application has integration cases that unit tests do not cover well.

There is also more governance than most language runtimes carry at the root: `CODE_OF_CONDUCT.md`, `CONTRIBUTING.md`, `SECURITY.md`, `FUNDING.yml`, `COPYING`, `LEGAL`, `BSDL` and `USERS.md`. The presence of a separate security policy and a legal directory reflects a project that gets used as infrastructure by other people, which is also why the CVE fixes above show up promptly in the release notes.

Tri-licensed, and the licence question is worth reading carefully

The README describes the licence as a tri EPL/GPL/LGPL scheme, meaning you may use, redistribute and modify the project under the terms of any one of three: Eclipse Public License version 2.0, or GNU General Public License version 2, or GNU Lesser General Public License version 2.1.

The choice among the three is deliberate and the usual reason for it. The LGPL is the permissive end for applications that link rather than embed, the GPL is the copyleft end, and the EPL is the file-level copyleft option that suits a project whose users want to modify it without the whole application becoming subject to copyleft. For most people picking JRuby, the practical effect is that none of the three options imposes a restriction they were worried about, which is why the tri-licence is offered at all.

There is a qualification. The README states that some components have other licences and copyright, and points at the COPYING file for specifics. With a codebase this size that is not surprising: parts of it come from the Ruby language itself, and the README credits code generously shared by Yukihiro Matsumoto, the creator of Ruby. LICENSE.RUBY and BSDL at the root are the evidence. If you are shipping JRuby inside a product, read COPYING rather than relying on the summary.

The author list in the README runs to several dozen names, ending with and many gracious contributors from the community, and the project contact is Thomas E Enebo. That is a reasonable picture of a project with two decades of accumulated contribution, and it is also a reminder that the tri-licence predates most of it.

Community and support, and where to look next

The README points to the project's website and its GitHub wiki for further information, and names Matrix as the place to talk, with the channel at #jruby on matrix.org. It also notes that core team members are in the EU and US time zones, which is a small practical fact for anyone deciding whether to expect an answer to a question.

What the README does not offer is a support commitment, and that is consistent with the shape of the project. It is a language runtime maintained in the open, so the realistic support path is the wiki, the issue tracker and the code itself. The advantage of that arrangement is that a question about JRuby's behaviour can usually be answered from the source, and the tree is arranged so that the relevant directory is findable.

For an evaluation, the questions worth asking are concrete. Does your application depend on C extensions, since those need a JVM-compatible build and the set that works varies by gem? Are you relying on a specific Ruby version's semantics, which decides 10.0.x against 10.1.x? And do you need the GIL removed, because if you do not, MRI may serve you better and JRuby's main argument weakens considerably.

The projects listed in USERS.md at the root of the repository are a better answer to the durability question than any claim about adoption. JRuby has been doing this since before most of the JVM tooling existed, and the presence of three maintained release lines with paired releases published the same evening is the practical evidence.

Editorial conclusion

JRuby's case has never been that it is Ruby but faster, because on most workloads it is not, and the project does not pretend otherwise. The case is that a JVM Ruby gets real parallelism without a global interpreter lock, it can reach JVM libraries without a bridge, and a Java application can embed it directly as a scripting language. Those three things are the reason the project has survived two decades of people predicting its demise, and the release notes show the maintenance is real rather than ceremonial: 10.1.2.0 fixed a macOS startup regression, improved Ruby subclasses of Java classes, and closed out a long tail of fiber scheduler fixes. Two practical notes if you are picking it up now. The version lines are not interchangeable, since 10.0.x targets Ruby 3.4 and 10.1.x targets Ruby 4.0, so your Ruby version requirement decides your line. And jruby-complete is now in deprecation, which means the standalone self-contained jar is on its way out and the version manager routes are the safer default.

Frequently asked questions

Official sources

1. Issues
2. jruby/jruby on GitHub
3. Project website
4. README
5. Releases