JEP 526, Lazy Constants (Second Preview), has been completed with a second preview, including changes after the first round of preview, namely JEP 502, Stable Values (Preview), for JDK 26. Formerly known as Stable Values, this feature introduces the concept of computed constants, which are immutable value holders initialized at most once. This provides the performance and safety benefits of final fields while offering greater flexibility in the timing of initialization. Revisions for this JEP include: changing the name from Stable Values to Lazy Constants, as the new name better captures the intent of a high-level use case and enhances discoverability.
The earlier Stable Values API exposed several low-level operations, such as setOrThrow, trySet, and orElseSet, which provided fine-grained control over initialization. According to the proposal, these operations were difficult to justify and often encouraged patterns that ran counter to the API’s intended purpose. JEP 526 replaces these mechanisms with a simpler, more ergonomic class, java.lang.LazyConstant<T>, which supports only factory-based initialization. The renaming clarifies the intent: instead of focusing on “stability via low-level control,” the new design emphasizes laziness coupled with immutability. Developers can now express deferred initialization without resorting to ad-hoc patterns like double-checked locking, holder classes, or nullable fields.
Using the new API, a lazy constant can be defined by providing a supplier function. The computed value is cached after the first access and never changes again. Consider the following example:
private static final LazyConstant<Logger> LOG =
LazyConstant.of(() -> Logger.create(MyService.class));
void run() {
LOG.get().info("service started");
}
This approach replaces older lazy-initialization idioms such as double-checked locking, holder classes, and nullable fields. Those patterns often required extra bookkeeping and careful manual thread safety. With LazyConstant, the JVM treats the computed value as a real constant once it has been initialized, opening the door to optimizations not possible with mutable lazy-initialization techniques.
Developers can also aggregate deferred values using lazy lists and lazy maps, which store each element in its own lazy constant. This allows collections to grow “on demand” rather than all at once. For example, an application can keep a pool of controllers without creating every instance upfront:
static final List<OrderController> ORDERS =
List.ofLazy(POOL_SIZE, _ -> new OrderController());
OrderController controller() {
long index = Thread.currentThread().threadId() % POOL_SIZE;
return ORDERS.get((int) index);
}
Each list element initializes only when first accessed, and subsequent calls return the cached controller. The same pattern works with named keys using a lazy map:
static final Map<String, OrderController> ORDERS =
Map.ofLazy(Set.of("Customers", "Internal", "Testing"),
_ -> new OrderController());
OrderController controller() {
return ORDERS.get(Thread.currentThread().getName());
}
These aggregated structures provide deferred initialization, thread-safety, and JVM optimizations while supporting more expressive access patterns.
One notable change from the earlier preview is that null is no longer allowed as a computed value. The designers note that disallowing null eliminates ambiguity, removes branching in the common path, and aligns with other unmodifiable constructs. This change also simplifies the mental model: a LazyConstant always yields a real value. Any attempt to treat null as a legitimate constant is now a design error.
The shift from Stable Values to Lazy Constants reflects a philosophical adjustment as well. Stable Values behaved somewhat like a low-level synchronization or atomic primitive with immutability layered on top. Lazy Constants, on the other hand, provide a high-level abstraction for everyday initialization scenarios. This makes the feature more suitable for libraries and frameworks, which can use lazy constants to reduce startup costs for components that may not be used in every application run. In addition, holding a LazyConstant in a final field allows the JVM to constant-fold the value after initialization, bringing together the reliability of immutability with the benefits of deferred computation.
JEP 526’s primary focus is developer ergonomics, but the performance implications are significant. Many applications initialize large graphs of objects or expensive resources such as loggers, configuration objects, or caches during startup. By allowing these to be represented as lazy constants, the startup path becomes lighter and more responsive. The API also guarantees that initialization occurs at most once, even in the presence of concurrency, without requiring the developer to implement synchronization manually. For large systems or modular architectures, the cost savings can accumulate quickly.
The preview continues to require explicit opt-in via --enable-preview during compilation and execution. The designers are seeking feedback on the simplified API surface, naming, and suitability for real-world workloads. According to the proposal, the team expects the revised design to be closer to what developers want: fewer mechanisms, more precise semantics, and better synergy with the JVM’s optimization pipeline. If the preview phase confirms this, Lazy Constants may become a permanent part of the platform in a future release.
As Java continues to adopt features that reduce boilerplate and improve performance while maintaining safety, Lazy Constants represent a natural evolution. If finalized, the feature will offer a more predictable and optimized alternative to the lazy-initialization idioms developers have used for decades, aligning with the platform’s broader goals of clarity, correctness, and performance.
