JRE (Java Runtime Environment)

Introduction

The Java Runtime Environment (JRE) is the environment required to run Java applications. It provides the components needed to execute Java bytecode, including the Java Virtual Machine (JVM) and the standard Java libraries used by Java applications.

When Java source code is compiled, it is converted into bytecode. That bytecode needs a runtime environment capable of loading the required classes, providing the necessary libraries, managing memory, and executing the program. The JRE represents this runtime layer.

The simplest way to understand the relationship is that the JVM executes Java bytecode, while the JRE provides the broader environment required for a Java application to run.

What is JRE?

JRE stands for Java Runtime Environment. It is the runtime layer of the Java platform that provides the components required to execute a compiled Java application.

Conceptually, the JRE consists of the JVM and the standard Java libraries required by applications.

                                 JRE                  │
          ┌───────┴────────┐
          │                │
         JVM       Java Standard Libraries
          │                │
          └───────┬────────┘
                  ↓
          Java Application

The JVM is responsible for executing bytecode, while the standard libraries provide commonly used functionality such as strings, collections, file handling, networking, and database access.

Why Do We Need the JRE?

A Java application does not consist only of the code written by the developer. It commonly depends on Java's standard APIs as well. For example, a simple program may use String, System, or ArrayList. These classes are provided by the Java platform libraries.

The JVM is responsible for executing bytecode, but an application also needs these libraries and other runtime facilities. The JRE represents this complete runtime environment.

For example:

public class Hello {    public static void main(String[] args) {
        System.out.println("Hello, Java!");
    }
}

After compilation, the resulting bytecode requires a Java runtime capable of loading the class, providing the required Java APIs, and executing the program.

Components of the JRE

The two main conceptual components of the JRE are the JVM and the Java standard libraries.

JVM

The JVM is the execution engine that runs Java bytecode. It loads classes, manages runtime memory, and executes the instructions contained in bytecode.

The JVM itself contains several important components, including the class loader, runtime data areas, execution engine, interpreter, JIT compiler, and garbage collection mechanisms. The JVM is therefore the part of the runtime responsible for actually executing the application.

Java Standard Libraries

Java applications rely heavily on the standard libraries provided by the Java platform. Some commonly used packages include java.lang for fundamental classes, java.util for collections and utility classes, java.io for input and output, java.net for networking, and java.sql for database connectivity.

These libraries provide functionality that developers would otherwise have to implement themselves.

How Does the JRE Run a Java Application?

A Java application typically begins as source code and is compiled into bytecode using the Java compiler.

 Java Source Code       ↓
     javac
       ↓
 Java Bytecode
       ↓
      JVM
       ↓
Java Application

The compiler belongs to the development environment provided by the JDK. Once the application has been compiled, the JVM can load and execute the resulting bytecode. During execution, the application can use the standard Java libraries provided by the runtime environment.

JVM vs JRE

JVM and JRE are related, but they are not the same thing. The JVM is the execution engine that runs Java bytecode, while the JRE is the broader runtime environment that conceptually includes the JVM and the Java libraries required by applications.

A simple way to remember the difference is:

JVM executes bytecode. JRE provides the environment needed to run Java applications.

The JVM handles execution, memory management, class loading, and runtime optimization, while the libraries provide reusable functionality to the application.

JRE vs JDK

The JDK and JRE have different purposes.

The JDK provides development tools such as javac, javadoc, jar, jdb, jshell, and jlink. The JRE represents the runtime side of the platform.

Conceptually:

 JDK │
 └── Runtime Environment
        │
        ├── Java Libraries
        │
        └── JVM

This is why developers normally install a JDK when learning or developing Java. It provides the development tools as well as the runtime capabilities needed to run Java applications.

JRE and Platform Independence

One of Java's most important characteristics is its portability. Java source code is compiled into bytecode rather than directly into machine code for a particular operating system. The bytecode can then be executed by a compatible JVM implementation on the target platform.

The important distinction is that Java bytecode is portable, while the JVM is platform-specific. A Java application can therefore use the same bytecode on different operating systems as long as a compatible JVM is available.

JRE and Memory Management

The JVM inside the runtime environment manages memory automatically. When an application creates objects, the JVM manages the memory associated with those objects. When objects are no longer reachable by the application, the garbage collector can reclaim their memory.

This means Java developers generally do not need to manually release memory using mechanisms such as free or delete. Automatic memory management is one of the important features of Java's managed runtime environment.

JRE and Garbage Collection

Garbage collection is handled by the JVM as part of runtime memory management. During execution, applications continuously create and use objects. When objects are no longer reachable, they become eligible for garbage collection, and the JVM can reclaim the memory associated with them.

Different Java versions and JVM implementations provide different garbage collectors, designed to address different performance and latency requirements.

JRE and Java Standard Libraries

The standard Java libraries are an important part of the runtime environment because applications depend on them for common programming tasks. Java provides APIs for collections, file operations, networking, input and output, database connectivity, date and time operations, and many other tasks.

These APIs allow developers to use common functionality without implementing everything from scratch.

Standalone JRE and Modern Java

There is an important difference between older Java releases and modern Java. Historically, Oracle distributed a separate JRE package for users who only needed to run Java applications. This was particularly common with older Java versions such as Java 8.

Starting with Java 11, Oracle stopped distributing a standalone JRE as part of its standard Java distribution. As a result, modern Java development generally uses the JDK rather than installing a separate JRE.

When a smaller runtime environment is required for deployment, the JDK provides the jlink tool. It can create a custom runtime image containing the Java modules required by a particular application.

JRE and jlink

jlink is a tool included with the JDK that can create a custom Java runtime image. Instead of deploying an entire JDK, developers can create a runtime containing only the modules required by their application. This can reduce the size of the runtime environment and provide more control over deployment.

This approach is particularly useful when applications are being packaged for production environments where minimizing the runtime footprint is important.

When Do You Need the JRE?

The JRE concept is mainly useful for understanding the runtime requirements of Java applications. If you are learning Java or developing Java applications, you normally install a JDK because it provides the compiler and other development tools along with the runtime capabilities.

For deployment, a custom runtime created using jlink can be useful when a smaller runtime environment is required. Therefore, modern Java development should generally not be based on older instructions that tell you to download a separate standalone JRE.

JRE vs JVM vs JDK

The three terms can be summarized simply:

JDK → Develop Java ApplicationsJRE → Provide the Runtime Environment
JVM → Execute Java Bytecode

The JDK is focused on development, the JRE represents the runtime environment, and the JVM is the execution engine responsible for running Java bytecode.

Key Takeaways

• JRE stands for Java Runtime Environment.

• The JRE represents the environment required to run Java applications.

• The JVM is responsible for executing Java bytecode.

• Java standard libraries provide commonly used APIs required by applications.

• The JVM manages runtime memory and garbage collection.

• Java bytecode is portable, while JVM implementations are platform-specific.

• The JDK is used for Java development and includes the tools required to compile and work with Java applications.

• Modern Java distributions generally do not provide a separate standalone JRE.

• jlink can be used to create a custom runtime image for deployment.

Conclusion

The JRE is the runtime layer of the Java platform. It provides the JVM and the standard Java libraries that a Java application needs during execution.The JVM handles the actual execution of bytecode, while the Java libraries provide the APIs that applications use for common operations. Together, these components provide the runtime environment for Java applications. For modern Java development, the JDK is normally the package developers install because it provides both development tools and the necessary runtime capabilities. When a smaller deployment environment is needed, jlink can be used to create a customized runtime. Understanding the JRE makes the relationship between the three core Java concepts much clearer: JDK for development, JRE for the runtime environment, and JVM for executing bytecode.