Java Runtime Environment

Definition

The Java Runtime Environment (JRE) is the software package required to run compiled Java applications, bundling the Java Virtual Machine, core class libraries, and supporting files needed for execution. It provides everything an end user's machine needs to launch a Java program without needing the compiler or development tools that a programmer uses to build that program in the first place. It is a subset of the full Java Development Kit.

Overview

Java programs are distributed as compiled bytecode rather than as native machine code, which means a machine running that program needs a piece of software capable of interpreting and executing that bytecode. The JRE exists to fill exactly that role: a runtime-only package that lets a computer execute Java applications without requiring the full development toolchain used to originally write and compile the program. Mechanically, the JRE bundles the Java Virtual Machine, which loads and executes compiled '.class' files, along with the core Java class libraries that provide fundamental functionality like collections, input and output, and networking that compiled programs depend on at runtime. When a user launches a Java application, the JRE's virtual machine reads the bytecode, verifies it, and interprets or just-in-time compiles it into native instructions for the underlying processor as the program runs. The JRE differs from the JDK in that it deliberately omits development-time tools such as the compiler, debugger, and documentation generator, since those are unnecessary for simply running a finished application. It also differs from the bare Java Virtual Machine alone in that it bundles the standard class libraries the JVM needs to actually execute typical programs, rather than being just the bytecode-execution engine by itself. In practice, end users historically installed a standalone JRE to run Java-based desktop applications and browser applets, though browser applet support has since been removed from modern browsers, shifting most JRE use toward server environments and bundled application distributions. Many modern Java applications now ship with a custom, minimal runtime image tailored to only the modules that application actually needs, rather than requiring a full general-purpose JRE installation. A key limitation historically associated with the JRE was version fragmentation: an application built against one Java version's libraries might behave differently or fail entirely on a machine with an incompatible JRE version installed, which is part of why bundling application-specific minimal runtimes became a preferred deployment approach. For pure development work, installing the standalone JRE is largely unnecessary today since installing the JDK already provides an internal JRE for testing. Server operators still track JRE update cycles closely, since security patches for the runtime are released on a regular cadence and running an outdated JRE in production leaves deployed applications exposed to known vulnerabilities that a current runtime would already have addressed. Container-based deployment has also shifted how the JRE is packaged in practice, with build pipelines commonly baking a specific minimal runtime image directly into an application's container so the exact runtime version ships alongside the code that was tested against it.

Key Features

• Bundles the Java Virtual Machine for executing bytecode
• Includes core Java class libraries needed at runtime
• Omits compiler and development-only tooling found in the JDK
• Verifies and executes compiled '.class' files at launch
• Historically required for standalone desktop Java applications
• Increasingly replaced by application-specific minimal runtime images

Use Cases

Alternatives

Frequently Asked Questions

Related in Programming