JetBrainsRuntime: the OpenJDK fork built for IntelliJ IDEs, with DCEVM and JCEF

Why OpenJDK alone does not fully cover IntelliJ-class desktop IDE requirements

JetBrainsRuntime exists because a graphical IDE at the scale of IntelliJ IDEA exercises parts of the JVM-to-operating-system boundary that standard OpenJDK does not prioritize. The areas JBR targets are specific: font rendering, keyboard support, the windowing and focus subsystems, HiDPI display scaling, accessibility, and desktop integration. At least some fixes in these areas are not yet present in OpenJDK.

On top of those incremental fixes, JBR carries 2 capabilities absent from standard OpenJDK: enhanced class redefinition through DCEVM, and Chromium browser embedding through JCEF. Both are opt-in rather than always present, and they serve different audiences.

JBR runs on Windows, Mac OS X and Linux. Because it is a fork of OpenJDK, not a separate JVM implementation, Java code that runs on OpenJDK runs on JBR without changes. The differences only appear where the JVM interacts with native display and input layers, and for headless server-side applications those layers are never exercised.

Main is a development branch; production builds come from jbr25, jbr21, jbr17 and jbr11

The main branch in the repository is explicitly a development branch, periodically synchronized with the OpenJDK master branch. The README notes this directly and points to 4 numbered branches as the source of production builds: jbr25 (based on JDK 25), jbr21 (JDK 21), jbr17 (JDK 17) and jbr11 (JDK 11).

For anyone who wants JBR for use with a JetBrains IDE, the path is the GitHub releases page for this repository. No build-from-source instructions or package manager command appears in the README. Multiple builds per month is the typical cadence, since JBR tracks IntelliJ product milestones rather than upstream JDK cycles.

8 download variants let you choose between JRE, SDK, JCEF, debug and Vulkan bundles

Every build on the releases page appears in multiple named variants, and choosing incorrectly means either missing a capability or carrying components you do not need.

JBR contains the Java Runtime Environment, suitable for running JVM programs. JBRSDK contains the Software Development Kit, suitable for both developing and running them. JBR with JCEF bundles both JBR and the JCEF Chromium framework; this is the variant shipped by default with all IntelliJ IDEs. Vanilla contains just JBR with no extras.

FreeType builds the freetype font library from sources rather than using the system copy. Vulkan includes experimental Vulkan rendering support. The debug symbols variant adds debug information to the usual bundle contents.

fastdebug is the variant with the clearest trade-off stated in the README: native binaries in this build are less optimized and easier to debug, but the README explicitly says they run much slower. It exists for diagnosing JVM-level problems, not for everyday IDE use.

DCEVM removes the method-body-only limit of standard HotSpot hot-reload

Standard OpenJDK HotSwap lets you change method bodies at runtime, but it does not allow adding methods, changing fields or altering class hierarchies while the JVM is running. DCEVM, which JBR carries, removes most of those limits. A class hierarchy change that would require a restart under HotSwap can go through immediately with DCEVM enabled.

For IntelliJ plugin developers and framework contributors running long-lived JVM processes, this distinction is practical. A typical server-side application that redeploys on restart gets nothing from DCEVM. An interactive desktop application that is expensive to restart benefits from being able to change class structure without killing the JVM.

The README names DCEVM as a supported JBR feature but does not specify which DCEVM version ships, nor does it clarify whether DCEVM is present in all 4 JDK base versions (jbr11 through jbr25).

The IDE-to-JBR mapping table has a version mismatch between display text and download URL

The README contains 4 tables mapping each IntelliJ IDE version to its recommended JBR build. This is the primary navigation aid for choosing which JBR to download, and reading it carefully matters before upgrading.

In the JDK 21 table, 2 rows contain a discrepancy between the version shown in the table cell and the version embedded in the linked GitHub tag. For IDE 2024.3, the cell shows 21.0.6-b631.52 but the tag in the download URL reads 21.0.7b631.52. For IDE 2024.2, the cell shows 21.0.4-b509.40 while the tag reads 21.0.7b509.40. The build number suffix (b631, b509) is consistent; only the JDK base version in the first part disagrees.

A developer who trusts the display column will record a different JBR version than the one actually installed. Following the URL link gives the correct download; reporting or pinning the version from the cell text gives a number that does not match any tag in the repository.

JCEF bundles Chromium for JVM applications; vanilla JBR omits it entirely

JCEF is a framework that lets a JVM application embed a Chromium-based browser inside a Java window. JBR includes it as an optional component. The README notes it is bundled by default with all IntelliJ IDEs, which means most IntelliJ users already have JCEF available without deliberately choosing it.

For developers building IntelliJ Platform plugins or standalone JVM desktop applications that need to render web content, JCEF is the component JBR adds. For applications with no web rendering requirement, the JBR with JCEF variant bundles Chromium binaries that serve no purpose, and vanilla or plain JBR is the lighter download.

The README gives no bundle size comparison between the JBR with JCEF and vanilla variants, so the size benefit of picking vanilla is not quantified in the available documentation.

Standard OpenJDK is adequate for server-side Java with no IntelliJ-specific dependencies

JBR's additions concentrate at the JVM-to-desktop boundary: font rendering, HiDPI scaling, JCEF, DCEVM. In a headless server environment, none of those apply. A Java service that happens to be developed with IntelliJ does not need JBR on the deployment server; the IDE runs on JBR and the server can run any compatible OpenJDK distribution.

The 2 cases where JBR genuinely replaces OpenJDK outside an IDE context are embedding JCEF in a custom JVM desktop application and using DCEVM to iterate faster on class structure during development. Both are deliberate opt-ins, not accidental benefits.

Anyone comparing JBR to other OpenJDK distributions like Eclipse Temurin or Amazon Corretto should note that those target broad production use, while JBR targets the specific needs of IntelliJ-style desktop tooling. The use case drives the choice.

Editorial conclusion

JetBrainsRuntime is the right JRE when you run IntelliJ-based IDEs and need DCEVM for enhanced class redefinition, or when you build a JVM desktop application that embeds Chromium through JCEF. For server-side or command-line Java applications, standard OpenJDK is adequate and the IDE-specific patches add nothing. Before switching, check the IDE-version-to-JBR table in the README for your IntelliJ build number, and note that the display version in the JDK 21 rows does not always match the tag in the linked download URL.

Frequently asked questions

Official sources

1. Issues
2. JetBrains/JetBrainsRuntime on GitHub
3. License: GPL-2.0
4. README
5. Releases