The roadmap is intentionally short. DDI is a nano library — every new feature has to earn its place against the “five public classes in the core” budget. Sponsorship moves items up the queue.

Now — 2026 Q2/Q3

• SaaS-policy tutorial series. Full end-to-end recipes for pricing-tier routing, quota-aware degradation, role-based impl selection, multi-tenant routing, and entitlements-as-injection. The DDI + jSentinel pair-up is the flagship narrative.
• Resolver tracing. When a ClassResolver picks an impl, you should be able to ask why. JFR events on resolution decisions, opt-in via system property.
• module-info.java for the JPMS folks. The library is small enough that a clean module descriptor is straightforward — getting the reflections8 story right is the actual work.

Next — 2026 Q4

• Virtual-thread-friendly scopes. The built-in JVMSingletonInjectionScope predates virtual threads. A ScopedValue-backed request scope is the obvious next step.
• Async resolver hook. Today a resolver runs synchronously. An async variant lets the resolver wait for an external policy decision (feature flag fetch, tenant lookup) without blocking the thread that’s injecting.
• Documentation: writing your own scope. The scope mechanism is one of the more powerful extension points and is currently under-documented.

Later — exploratory

• An interactive resolution-rules picker on the docs site: “I have N impls, M producers, K resolvers — what happens?” A direct UX win for new users.
• Records-based producer descriptors. Reduce the boilerplate for declaring multiple producers for the same impl.
• Spring / Quarkus interop adapters. Carve-outs that let you use DDI for one hot module inside an otherwise Spring-driven app.

Out of scope

To keep the surface small, these stay outside DDI proper:

• A built-in feature-flag client. That lives in your resolver, not in DDI.
• An AOP / interception layer. DDI injects implementations; what they do is the implementation’s business.
• A configuration framework. Use core-properties or whatever you already have.
• A managed lifecycle (“application context”). DDI’s surface is DI.activatePackages and DI.activateDI. That’s the lifecycle.

See something missing, or have a use case the current API doesn’t cover well? [Open an issue]({{ .Site.Params.github }}/issues) — concrete code-level reports beat abstract feature requests every time.