Jakarta CDI 5.0 Is GA: The First Jakarta EE 12 Spec Ships

Jakarta CDI 5.0 went GA on September 9 as the first specification approved for Jakarta EE 12. If you are running any Jakarta EE stack — Quarkus, WildFly, Open Liberty, Payara — CDI is the wiring underneath everything: scopes, lifecycle, injection, events. Version 5.0 adds annotations you will actually use, an async invoker API, and one genuinely breaking change. Your Maven coordinates just moved. Update before your next CDI bump lands and breaks your build.

The Breaking Change: Maven Coordinates Moved

Both the groupId and artifactId changed in CDI 5.0. This is not optional and will not silently resolve — your dependency manager will tell you something is wrong once you upgrade.

Old coordinates (CDI 4.x):

<dependency>
  <groupId>jakarta.enterprise</groupId>
  <artifactId>jakarta.enterprise.cdi-api</artifactId>
</dependency>

New coordinates (CDI 5.0):

<dependency>
  <groupId>jakarta.cdi</groupId>
  <artifactId>jakarta.cdi-api</artifactId>
  <version>5.0.0</version>
</dependency>

The CDI API JAR ships relocation artifacts to smooth the transition. The TCK does not — update those coordinates manually. Your beans.xml schema version should move to 5.0, though the namespace is unchanged and the schema is backward compatible with CDI 4.1. Java 17 is now the minimum runtime. Check the official CDI 5.0 specification for the complete change log.

@AutoClose: Annotation-Driven Resource Cleanup

Add @AutoClose to any bean that implements java.lang.AutoCloseable, and CDI calls close() automatically during destruction. No more @PreDestroy boilerplate wrapping a try-catch to release a connection or close a stream.

Before CDI 5.0:

@ApplicationScoped
public class DatabasePool {
    @Inject DataSource ds;

    @PreDestroy
    public void cleanup() {
        try { ds.close(); } catch (Exception e) { /* log */ }
    }
}

With CDI 5.0:

@ApplicationScoped
@AutoClose
public class DatabasePool implements AutoCloseable {
    @Inject DataSource ds;

    @Override
    public void close() throws Exception {
        ds.close();
    }
}

@AutoClose works on managed beans, producer methods, and producer fields. It can also be placed on stereotypes, so a single stereotype can enforce auto-cleanup across an entire application layer.

@Eager: Force Startup Initialization

Lazy initialization is CDI’s default. Most of the time that is fine. When it is not — connection pools that need to fail fast, caches that need to pre-warm, health endpoints that must return 200 immediately — you have had to work around it. @Eager removes the workaround.

@Eager
@ApplicationScoped
public class StartupCache {
    @PostConstruct
    public void preload() {
        // runs at startup, not on first injection
    }
}

The constraint is firm: @Eager is only valid on @ApplicationScoped beans. Applying it to any other scope is a definition error at deployment time. That is intentional. Eager initialization of request-scoped or session-scoped beans does not make architectural sense, and CDI 5.0 is not pretending otherwise.

Async Invokers and the AsyncHandler API

CDI 5.0 adds the AsyncHandler API to the method invokers section of the spec. Frameworks can now invoke managed bean methods asynchronously without wiring their own executor logic into every call. This matters more for framework authors than application developers, but it unblocks reactive and event-driven integration patterns that previously required stepping outside CDI’s managed lifecycle. If you build on top of CDI rather than just with it, read the full specification section on method invokers.

What Was Removed

Three things are gone in CDI 5.0. The Unified EL integration methods on BeanManager have been removed — they moved to ELAwareBeanManager back in CDI 4.1, so this should not surprise anyone still on a supported runtime. SecurityManager usage is gone throughout the spec, consistent with Java 17’s deprecation and removal path. bean-discovery-mode="trim" is now forbidden in non-explicit bean archives.

The older SyntheticBeanCreator and SyntheticBeanDisposer method signatures are deprecated for removal, replaced by the new SyntheticInjections API. If you are a framework author relying on these, start the migration now rather than on the next major version.

The Jakarta EE 12 Signal

CDI 5.0 is the first Jakarta EE 12 specification approved by the Specification Committee. That matters because CDI is what most other EE 12 specs will depend on. Jakarta REST 5.0, JSON Binding 3.1, the new Data 1.1, and the entirely new Jakarta Query 1.0 specification — a unified query layer for relational and NoSQL repositories — can now all target CDI 5.0 features. The full EE 12 platform GA is on track for Q2 2027.

Weld 7.0.0.CR1, the CDI reference implementation, was submitted for compatibility certification on August 4. Production stacks running WildFly, JBoss EAP, and Open Liberty should expect Weld 7 to land as EE 12 implementations mature through the rest of 2026 and into 2027.

Migration Checklist

• Update Maven dependency to jakarta.cdi:jakarta.cdi-api:5.0.0
• Update TCK coordinates manually (no relocation artifacts provided)
• Bump beans.xml schema to version 5.0
• Migrate BeanManager EL methods to ELAwareBeanManager
• Remove SecurityManager guards in portable extensions
• Replace SyntheticBeanCreator/SyntheticBeanDisposer with SyntheticInjections
• Confirm Java 17+ runtime is in place
• Remove bean-discovery-mode="trim" from non-explicit archives