Java Terms Explained on foojay.io - Friends of OpenJDK

AOT Compilation (Ahead-of-Time)

Mon, 01 Jan 0001 00:00:00 +0000

Ahead-of-time (AOT) compilation converts Java source code or bytecode into native machine code before the application runs, rather than during execution. The result is a self-contained native binary that starts nearly instantly, without the warm-up phase that a JIT-compiled JVM requires.

Traditional JVMs start by interpreting bytecode and then JIT-compiling hot methods at runtime. This produces excellent peak throughput but means applications take seconds — sometimes tens of seconds for framework-heavy apps — to reach full speed. AOT compilation eliminates that delay by doing the compilation work once, at build time.

Basic Java Concepts

Mon, 01 Jan 0001 00:00:00 +0000

The Java programming language and Java virtual machine (also known as Java runtime environment) provide the tools to write operating system independent applications. A Java application employs the JVM (Java Virtual Machine) on the target system to run its code. Java applications are therefore independent from the JVM and one can be updated/patched independent from the other.

A Java application is deployed in a platform-independent deployment format called Byte Code. Byte Code is commonly packaged and shipped as a collection of “.jar” files. The compilation and packaging of Java source code into JAR files is a comparatively lightweight process that does not create a classical CPU and OS dependent binary. To run a Java application, a platform-specific Java Runtime Environment (JRE) or Java Virtual Machine (JVM) is required.

Bytecode

Mon, 01 Jan 0001 00:00:00 +0000

When you compile a Java source file, the Java compiler (javac) does not produce native machine code for a specific CPU. Instead it produces bytecode : a compact, platform-neutral instruction set stored in .class files. Bytecode is not directly understood by the operating system; it is executed by the Java Virtual Machine (JVM), which translates it into native instructions at runtime.

This two-step model — compile once to bytecode, run anywhere on a JVM — is the foundation of Java’s “write once, run anywhere” promise. The same .class file runs without modification on Windows, Linux, or macOS, as long as a compatible JVM is available.

Class Loading

Mon, 01 Jan 0001 00:00:00 +0000

Before the JVM can execute any code it must load the corresponding .class file into memory. This process is handled by class loaders, which locate, read, and define classes at runtime. Class loading is lazy by default: a class is not loaded until it is first referenced.

The JVM has a hierarchy of built-in class loaders. The bootstrap class loader loads the core Java platform classes from the JDK itself. The platform class loader (formerly extension class loader) loads JDK extension modules. The application class loader loads classes from the application’s classpath or module path. Custom class loaders can be written to load classes from databases, networks, or encrypted archives.

Compact Profiles

Mon, 01 Jan 0001 00:00:00 +0000

Note: Compact Profiles are a Java 8 feature. Starting with Java 9, the same goal — creating a minimal, self-contained runtime — is achieved more flexibly by jlink and the Java Module System (JPMS). If you are working with Java 9 or later, see Java Module System (JPMS) instead.

Introduced in OpenJDK 8 (JSR 337), compact profiles define three nested subsets of the Java SE 8 API designed to reduce the runtime footprint on resource-constrained devices such as embedded systems and IoT hardware.

CPU and PSU

Mon, 01 Jan 0001 00:00:00 +0000

From Java 9 onward, Oracle moved to a six-month release cadence, releasing a new JDK version every March and September. Security patches, bug fixes, and critical updates are delivered in three ways:

CPU (Critical Patch Update) — Oracle’s quarterly security update, released in January, April, July, and October. Each CPU for a supported JDK version contains all security fixes accumulated since the previous CPU.

PSU (Patch Set Update) — A superset of the CPU that also includes non-security bug fixes. PSUs are available for the same cadence but recommended primarily for users who have encountered specific bugs fixed in that release.

CRaC (Coordinated Restore at Checkpoint)

Mon, 01 Jan 0001 00:00:00 +0000

CRaC is an OpenJDK project that solves one of the most common complaints about Java in cloud environments: slow startup. The JVM traditionally takes time to load classes, initialise frameworks, and warm up the JIT compiler before an application can serve its first request. In a serverless or container-heavy deployment, this warmup cost is paid every time a new instance starts.

CRaC addresses this by letting you take a checkpoint of a fully-warmed, running JVM process — capturing its complete in-memory state — and then restore that snapshot on demand. A restored process skips the entire startup and warmup sequence, reaching full speed in milliseconds.

Disco API

Mon, 01 Jan 0001 00:00:00 +0000

The Disco API (short for Universal OpenJDK Discovery API) is a database and REST API that catalogues every available OpenJDK package from every major distributor — Temurin, Zulu, Corretto, Liberica, Oracle, and many others — in one place. It covers every combination of Java version, operating system, CPU architecture, package type (JDK or JRE), and archive format, with tens of thousands of packages indexed.

The API is maintained by Foojay and developed by Gerrit Grunwald. Its source code is available on GitHub . The base URL for the REST endpoints is https://api.foojay.io/disco/v3.0/, and a full Swagger UI makes the API easy to explore interactively. Key endpoints let you query major versions, list all distributions, and filter packages by any combination of version, architecture, OS, and JavaFX bundling.

Epsilon GC

Mon, 01 Jan 0001 00:00:00 +0000

Epsilon GC is a no-op garbage collector : it allocates memory on request but never reclaims it. When the Java heap is exhausted, the JVM exits with an OutOfMemoryError. It was introduced as an experimental feature in Java 11 (JEP 318).

Epsilon sounds counterproductive, but it has legitimate use cases:

Performance benchmarking — GC activity introduces timing noise in microbenchmarks. Epsilon eliminates that noise, giving a clean measure of allocation and computation cost. Tools like JMH may benefit from Epsilon when benchmarking short-lived workloads.
Short-lived command-line tools — If an application runs for a fraction of a second and allocates only a few megabytes, GC overhead may outweigh any benefit. Epsilon reduces per-run latency to essentially zero.
Allocation testing — Engineers building GC-aware libraries can use Epsilon to verify that their code does not allocate unexpectedly, since any allocation under Epsilon is permanent and will eventually cause OOM.

Epsilon is not suitable for long-running applications or workloads with significant allocation. It requires explicitly unlocking experimental options:

Foreign Function & Memory API

Mon, 01 Jan 0001 00:00:00 +0000

The Foreign Function & Memory (FFM) API, finalised in Java 22 (JEP 454), provides a safe, efficient, and pure-Java way to interact with native code and off-heap memory — replacing the older, error-prone Java Native Interface (JNI).

Foreign memory access allows Java programs to allocate, read, and write memory outside the Java heap using MemorySegment. Off-heap allocation is useful for large data structures that should not be managed by the GC, for memory-mapped files, and for shared memory between processes. The API enforces lifetime tracking: a MemorySegment is associated with an Arena, and its memory is released deterministically when the arena is closed.

Garbage Collection

Mon, 01 Jan 0001 00:00:00 +0000

Garbage Collection (GC) is the process by which the JVM automatically reclaims memory occupied by objects that are no longer reachable by the running application. Java developers do not call free() or delete() as in C or C++; the garbage collector handles memory management automatically.

Most JVM garbage collectors divide the heap into generations. The assumption — the “generational hypothesis” — is that most objects die young. New objects are allocated in the young generation, which is collected frequently and cheaply. Objects that survive long enough are promoted to the old generation, which is collected less often but at greater cost.

GC Algorithms: G1, ZGC, and Shenandoah

Mon, 01 Jan 0001 00:00:00 +0000

The JDK ships with several garbage collectors, each designed for different goals. Choosing the right one depends on whether your application prioritises throughput, latency, or predictability.

Serial GC

The simplest collector, designed for single-threaded or very small-heap applications. It uses a single thread for both young and old generation collection and is the default in environments with a single CPU or very small heaps (under ~100 MB). For constrained containers or command-line tools, Serial GC has the lowest overhead. Use -XX:+UseSerialGC.

GraalVM and Native Image

Mon, 01 Jan 0001 00:00:00 +0000

GraalVM is a high-performance JDK distribution and runtime developed by Oracle. It extends the standard JDK with two key capabilities: the Graal JIT compiler (a Java-written replacement for HotSpot’s C2 JIT that can deliver improved peak throughput for certain workloads) and Native Image (an AOT compilation tool that produces self-contained native executables).

GraalVM Native Image performs a closed-world static analysis of the entire application at build time — tracing all reachable code, classes, and resources — then compiles the result to a native binary using Substrate VM, a minimal VM embedded in the output. The resulting executable:

Heap Dump

Mon, 01 Jan 0001 00:00:00 +0000

A heap dump is a snapshot of all the objects in a Java process’s heap memory at a specific point in time, written to a file. It captures every object, its class, its size, and the references connecting objects to each other.

Heap dumps are an essential tool for diagnosing memory-related problems. If your application is running out of memory, growing slowly over time (a memory leak), or consuming far more RAM than expected, a heap dump lets you see exactly what is occupying the heap and trace why objects are being retained.

Jakarta EE

Mon, 01 Jan 0001 00:00:00 +0000

Jakarta EE is the open-source, community-driven successor to Java EE (Java Platform, Enterprise Edition). It defines a set of specifications for building enterprise Java applications — covering everything from web services and dependency injection to persistence, messaging, and security.

The name change happened when Oracle transferred stewardship of Java EE to the Eclipse Foundation in 2017. The transition involved more than a rename: because Oracle retained the javax.* namespace, Jakarta EE 9 (released in 2020) migrated all specifications from javax.* packages to jakarta.*. This was a breaking change — existing code importing javax.servlet, javax.persistence, and similar packages had to be updated — but it gave the community full ownership of the platform going forward.

Java Champion

Mon, 01 Jan 0001 00:00:00 +0000

A Java Champion is a recognised leader, educator, or innovator in the Java community — someone who has demonstrated a sustained, meaningful contribution to the broader Java ecosystem through writing, speaking, open-source work, community building, or technical excellence.

The program is managed by Oracle. Existing Java Champions nominate and vote on new candidates; Oracle holds veto rights but does not unilaterally elect members. The process is intentionally community-driven to keep the designation credible and peer-recognised. Approximately 400 Java Champions have been recognised worldwide as of 2026.

Java Community Process (JCP)

Mon, 01 Jan 0001 00:00:00 +0000

The Java Community Process (JCP) is the formal mechanism through which the Java platform specifications are created and evolved. Established in 1998, it allows Java community members — companies, organisations, and individuals — to participate in defining the future of Java SE, Jakarta EE, and related specifications.

Changes to the Java platform specification are proposed as Java Specification Requests (JSRs). A JSR defines an API or platform feature and goes through a multi-stage process: initiation, expert group formation, public drafts, a final ballot, and maintenance updates. Each JSR produces a specification document, a Reference Implementation (RI), and a TCK.

Java Module System (JPMS)

Mon, 01 Jan 0001 00:00:00 +0000

The Java Platform Module System (JPMS), introduced in Java 9 as part of Project Jigsaw, brings a formal module concept to the Java platform. A module is a named, self-describing collection of packages. Each module declares what it exports (makes available to other modules) and what it requires (depends on), in a module-info.java file at the root of the source tree.

Before JPMS, the JVM had only the concept of the classpath — a flat list of jars with no enforced boundaries between them. Any code could access any public class from any jar, which made large codebases hard to reason about and the JDK itself monolithic. JPMS enforces encapsulation: a package that is not explicitly exported is simply not accessible to code in other modules, even if it is public.

Java Native Interface (JNI)

Mon, 01 Jan 0001 00:00:00 +0000

The Java Native Interface (JNI) is the standard mechanism that allows Java code running in the JVM to call, and be called by, native code written in C, C++, or other languages that can produce a shared library. It has been part of Java since version 1.1.

JNI is used when Java needs to interact with platform-specific functionality (hardware access, OS APIs, existing C libraries), for performance-critical code where a native implementation is significantly faster, or to integrate with existing native codebases that cannot be rewritten in Java.

JDK Distributions

Mon, 01 Jan 0001 00:00:00 +0000

The OpenJDK project publishes source code, not binaries. To actually run Java, you need a distribution: a pre-built, tested binary of OpenJDK packaged by a vendor. Multiple vendors publish OpenJDK distributions, each adding their own packaging, support commitments, and sometimes additional features or patches.

All major distributions are built from the same OpenJDK source and must pass the TCK to be labelled “Java SE compatible”. In practice they are interchangeable for most applications. The main differentiators are support terms, supported platforms, update frequency, and optional extras.

JDK Mission Control (JMC)

Mon, 01 Jan 0001 00:00:00 +0000

JDK Mission Control is a suite of tools for profiling, monitoring, and diagnosing Java applications. It provides a GUI frontend for Java Flight Recorder (JFR) data and a live connection to running JVMs via JMX.

JMC was originally developed by BEA Systems as JRockit Mission Control, acquired by Oracle with BEA in 2008, and open-sourced under the Eclipse Foundation in 2018 (project name: JDK Mission Control, or JMC). It is available as a standalone download and as a plugin for Eclipse IDE and IntelliJ IDEA.

JEP (JDK Enhancement Proposal)

Mon, 01 Jan 0001 00:00:00 +0000

A JDK Enhancement Proposal (JEP) is the formal document used to propose, track, and communicate a significant change to the Java platform. Every major language feature, JVM improvement, or API addition that ships in a JDK release starts life as a JEP.

A JEP describes the motivation for the change, its goals and non-goals, the proposed design, and the alternatives considered. JEPs go through a lifecycle of states — Draft, Submitted, Candidate, Proposed to Target, Targeted, Integrated, Complete — before a change lands in a release.

JFR (Java Flight Recorder)

Mon, 01 Jan 0001 00:00:00 +0000

Java Flight Recorder (JFR) is a low-overhead profiling and event-collection framework built into the JDK. It records a continuous stream of events about the JVM and the running application — garbage collection pauses, thread states, CPU usage, I/O, exception throws, and hundreds more — with negligible impact on application performance (typically less than 1% overhead).

JFR was originally a commercial feature in Oracle JDK and was open-sourced and contributed to OpenJDK in JDK 11. It is enabled with a simple JVM flag (-XX:StartFlightRecording) or programmatically via the jdk.jfr API, and recordings can be made in a continuous loop or for a fixed duration.

JIT Compilation (Just-in-Time)

Mon, 01 Jan 0001 00:00:00 +0000

Just-in-time (JIT) compilation is the process by which the JVM translates bytecode into native machine code while the application is running, rather than before it starts. This is the mechanism responsible for Java’s high peak throughput: the JVM profiles running code and compiles only the methods that are actually “hot” (frequently executed), applying increasingly aggressive optimisations as confidence in the profile grows.

The JVM starts by interpreting bytecode. When a method has been called enough times to cross a threshold, the JIT compiler (C1, the client compiler) produces an initial native compilation with limited optimisation. If the method continues to be called heavily, the more aggressive C2 (server compiler) recompiles it with speculative optimisations — inlining, loop unrolling, escape analysis, and more. This two-tier strategy (called tiered compilation, the default since Java 8) balances fast startup with high peak performance.

jtreg Test Suites

Mon, 01 Jan 0001 00:00:00 +0000

jtreg is the test harness for regression and unit testing used by the JDK test framework. For many OpenJDK distributions, the jtreg tests are run in addition to the TCK to provide broader coverage of JVM behaviour and standard library correctness.

The OpenJDK source repository (hosted at github.com/openjdk/jdk ) contains tens of thousands of jtreg tests. As of Java 21, the test suite contains over 100,000 individual test cases across the test/ directory tree — covering the compiler, JVM, standard libraries, and tools. The count grows with every release.

Latency

Mon, 01 Jan 0001 00:00:00 +0000

Latency is the time between the initiation of a procedure and the completion of the procedure; in other words, how long it takes for something to happen.

In the realm of software, there are many types of latency. No application can possibly be truly real-time (that is, zero latency: zero time elapses between the initiation of the procedure and the delivery of the result). Still, the objective of all high-performance applications is to be as close to real-time as possible.

LTS and Non-LTS Releases

Mon, 01 Jan 0001 00:00:00 +0000

Since Java 9, the JDK has followed a strict six-month release cadence: a new version ships every March and September. Most of these are feature releases with a short support window — typically six months, until the next version arrives. These are sometimes called non-LTS, short-term support (STS), or simply feature releases.

Every few years, one release is designated Long-Term Support (LTS). LTS releases receive security patches and bug fixes for a significantly longer period — at least several years for most vendors, and often much longer with commercial support agreements. Java 8, 11, 17, 21, and 25 are LTS releases. The interval between LTS releases shifted from three years (8→11→17) to two years (17→21→25) starting with Java 21.

OpenJDK

Mon, 01 Jan 0001 00:00:00 +0000

OpenJDK is the open-source reference implementation of the Java Platform, Standard Edition (Java SE) specification. It is the upstream project from which virtually all Java distributions are built. OpenJDK is source code, not a runnable binary — to run Java applications you need a distribution built from that source.

Oracle leads OpenJDK development and contributes the majority of the code, but the project has contributions from Amazon, Microsoft, Red Hat, SAP, Azul, Google, and many individual developers. Governance follows the OpenJDK bylaws, with an Author → Committer → Reviewer hierarchy. New features are proposed via JEPs (JDK Enhancement Proposals) .

OpenJDK Coding Guidelines and Code Reviews

Mon, 01 Jan 0001 00:00:00 +0000

OpenJDK does not have a single exhaustive coding style guide. Sub-components come from diverse origins (HotSpot, the standard library, OpenJFX, etc.) and each has its own conventions. The main reference documents are:

Developer’s Guide: openjdk.org/guide/ — covers the development process, code conventions, changeset format, and review workflow.
How to Contribute: openjdk.org/contribute/ — prerequisites, JCA (Oracle Contributor Agreement), and getting started.
HotSpot Style Guide: wiki.openjdk.org/display/HotSpot/StyleGuide — C++ conventions for JVM internals.
OpenJFX: wiki.openjdk.org/display/OpenJFX/Committing+the+Code and Code Reviews .

Code Reviews and Code Quality

Changes to OpenJDK are reviewed and approved by Reviewers — contributors with Reviewer role in a given repository. Multiple Reviewers must approve a change before it is integrated; the exact number depends on the sub-project. The integration itself is performed by a Committer using the OpenJDK GitHub bots (the Skara tooling).

OpenJDK Projects

Mon, 01 Jan 0001 00:00:00 +0000

OpenJDK is organised into named Projects : focused research and development efforts that explore or implement significant improvements to the Java platform. Each project has its own mailing list, repository, and contributor community. Successful work in a project typically results in one or more JEPs that integrate the work into mainline JDK releases.

The most significant active and recent projects:

Project Loom — Delivered virtual threads (Java 21), structured concurrency, and scoped values. Aims to make concurrent Java programming dramatically simpler and more scalable by replacing thread-per-request models with lightweight virtual threads.