Find JSRs
Submit this Search

Ad Banner

Summary  |  Proposal  |  Detail (Summary & Proposal)  |  Nominations
JSRs: Java Specification Requests
JSR 365: Contexts and Dependency Injection for JavaTM 2.0

Stage Access Start Finish
Final Release Download page 22 May, 2017  
Final Approval Ballot View results 25 Apr, 2017 08 May, 2017
Proposed Final Draft Download page 06 Apr, 2017  
Public Review Ballot View results 07 Mar, 2017 20 Mar, 2017
Public Review Download page 31 Jan, 2017 02 Mar, 2017
Early Draft Review 2 Download page 30 Aug, 2016 14 Oct, 2016
Early Draft Review Download page 08 Jul, 2015 05 Oct, 2015
Expert Group Formation   26 Aug, 2014 29 Apr, 2015
JSR Review Ballot View results 12 Aug, 2014 25 Aug, 2014
JSR Review   28 Jul, 2014 11 Aug, 2014
Status: Final
JCP version in use: 2.10
Java Specification Participation Agreement version in use: 2.0

This JSR is a major evolution of the CDI 1.1 (JSR 346) specification. Focused on modularity and Java SE support.

Expert Group Transparency:
  Public Project Page
  Public Communications
  Issue Tracking


Specification Leads
Star Spec Lead Antoine Sabot-Durand Red Hat
Expert Group
  Credit Suisse
: Anatole Tresch
Goncalves, Antonio
: Antonio Goncalves
: Emily Jiang
  Janssen, Thorben
: Thorben Janssen
JUG Chennai
: Rajmahendra Hegde
Werner Keil
  Knitelius, Stephan
: Stephan Knitelius
: Joseph Snyder
Mark Paluch
  Paumard, Jose Red Hat
: George Gastaldi
Red Hat
: Martin Kouba
  Red Hat
: Pete Muir
Red Hat
: Antoine Sabot-Durand
Otavio Santana
: Florent BENOIT
Sparta Systems
: John Ament
Mark Struberg
: David Blevins
Trivadis AG
: Anatole Tresch

Updates to the Original JSR

The following changes have been made to the original proposal:


Pete Muir is no longer co-Specification Lead of this JSR.

Original Java Specification Request (JSR)

Identification | Request | Contributions

Section 1. Identification

Submitting Member: RedHat

Name of Contact Person: Antoine Sabot-Durand

E-Mail Address:

Telephone Number: +33 608 553 426

Fax Number: +33957700120

Specification Lead: Pete Muir,   Antoine Sabot-Durand

E-Mail Address:,

Telephone Number: +447769557110,   +33 608 553 426

Fax Number: +33957700120

Note that this information has been updated from this original proposal; Pete Muir stepped down as Specification Lead on 28.07.2015.

Initial Expert Group Membership:


Supporting this JSR:

JUG Chennai
Morocco JUG
London Java Community JUG
John Ament
Markus Eisele
Adam Bien
Antonio Goncalves
Michael Nascimento Santos
Werner Keil

Section 2: Request

2.1 Please describe the proposed Specification:

Contexts and Dependency Injection (CDI) 1.0 focused strongly on Java EE, and was first delivered as part of Java EE 6. Since delivery of Java EE 6, CDI has become increasingly popular, and is now seen as the core of Java EE and in most new Java EE projects. CDI 1.1 was a minor update to CDI 1.0, and focused on resolving any issues from CDI 1.0, as well as providing better integrations for other Java EE specs.

We have heard strong feedback from both the Java EE community (including the Java EE 8 survey:), and the wider Java community, that they would like CDI to be more widely available in other Java EE specifications as a transverse integration solution, and be able to run outside of a Java EE container. There are a number of reasons for this last need:

1. DI is a popular approach to build any type of application, not just enterprise applications, and there is no standardized DI for Java

2. Allow users to use the same wiring model in both Java SE and Java EE. Often Java EE component specifications such as JPA or JAX-RS are used outside of the Java EE platform. They would like to be able to require a DI environment in Java SE as well as Java EE. Would it be of use to mention DeltaSpike or the positive results from introducing CDI-SE features?

3. Often users will test their application outside of an app server. Requiring a CDI implementation to support working in Java SE makes for easier testing

CDI 2 would deliver a major update to CDI 1.1, and focus on two main features:

1. Define the behavior of CDI outside of a Java EE container.

2. Make CDI more modular to help other Java EE specs to better integrate with it.

At this point we are proposing to define how CDI should run in Java SE, as well as introducing new features to make CDI in Java SE more useful. We are not proposing that CDI would be part of the JDK.

We believe there are five major tasks required:

1. The specification and TCK require a significant overhaul to be split into two parts.
a. Part 1: The core CDI programming model
b. Part 2: Java EE integrations for CDI.

2. Defining a portable bootstrap API for CDI. Currently CDI does not define an API for bootstrap, instead relying on a Java EE deployment to start the container. Additionally, we would like to introduce a programmatic API for binding beans, allowing much greater flexibility for portably wiring a container.

3. The context model in CDI is based around the thread-bound request-response model. This model is more prevalent in web applications than elsewhere, and, also is less pervasive than it once was. We would like to overhaul the context model to allow the application or container to portably push the active context to CDI when it requires the use of CDI. This change would be largely transparent to applications, and we might want to consider an API facade over it

4. Introduce modularity to CDI. One of the most often given reason by other JSR or frameworks to limit their CDI adoption is the size of the specification. Too big, too many features. CDI is becoming an important component model in Java EE, and we think that learning from the experience of long running specifications of specifications (like EJB) is important. Before we starting adding features to CDI, we want to see if we can introduce ?parts?, to avoid creating a spec that gives the impression of being big and heavy.
There's already some preparation work around this topic. The following document is a draft of what these modules could be (only leads for the moment, nothing decided).

5. Define a lightweight container, which takes the annotations specified by the @Inject specification, defines the behaviour of the container (which @Inject failed to do), and adds a couple of popular features from CDI such as producer methods. This will allow much wider adoption of CDI in the Java world, and provide a great stepping stone between Java SE, a servlet container, OSGi and a full Java EE server.

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

Java(TM) SE and Java(TM) EE platforms.

2.3 The Executive Committees would like to ensure JSR submitters think about how their proposed technology relates to all of the Java platform editions. Please provide details here for which platform editions are being targeted by this JSR, and how this JSR has considered the relationship with the other platform editions.

The work will track Java(TM) EE 8, to be released as part of the Java(TM) EE 8 platform. The Java(TM) SE support of the spec will be based on Java(TM) SE 8.

2.4 What need of the Java community will be addressed by the proposed specification?

The goal of the proposed specification is to address the needs of the Java community by augmenting the functionality of Contexts and Dependency Injection to address requests received from the Java community for additional features.

2.5 Why isn't this need met by existing specifications?

See 2.4 above. These new features are specific to the Contexts and Dependency Injection architecture, which does not yet provide them.

2.6 Please give a short description of the underlying technology or technologies:

See above.

2.7 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)

The API specification will continue to use the javax.enterprise package.

2.8 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?


2.9 Are there any security issues that cannot be addressed by the current security model?


2.10 Are there any internationalization or localization issues?


2.11 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?


2.12 Please describe the anticipated schedule for the development of this specification.

* August 2014 Expert Group formed
* Q1 2015 Early Draft
* Q3 2015 Public Review
* Q1 2016 Final Release

2.13 Please describe the anticipated working model for the Expert Group working on developing this specification.

The primary means of communication will be the existing mailing list (, IRC channel (#cdi-spec on freenode).
Phone conferences and face-to-face meetings will be scheduled if needed.

2.14 Provide detailed answers to the transparency checklist, making sure to include URLs as appropriate:

We will leverage the collaborative tools provided by the JBoss Community infrastructure.

We have a public issue tracker for tracking most issues at

We have a public EG discussion list at which is free for anyone to join and post to.

We also provide an IRC channel (#cdi-spec on freenode) to have meetings.

The reference implementation will be developed entirely in the public Weld project in the JBoss Community. The TCK will be developed entirely in the public CDI TCK in the JBoss Community. We will leverage the JCP 2.9 procedures to allow the public to see the spec in progress.

2.15 Please describe how the RI and TCK will de delivered, i.e. as part of a profile or platform edition, or stand-alone, or both. Include version information for the profile or platform in your answer.

Red Hat, Inc. will deliver a Reference Implementation (RI) and Technology Compatibility Kit (TCK) compatible with Java EE 8 and license compatible with Java EE licensing as part of the final specification.

2.16 Please state the rationale if previous versions are available stand-alone and you are now proposing in 2.13 to only deliver RI and TCK as part of a profile or platform edition (See sections 1.1.5 and 1.1.6 of the JCP 2 document).


2.17 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.

* The specification will be licensed using the standard specification license (
* The RI and TCK will be licensed via the Apache License 2.0 (

2.18 Please describe the communications channel you have established for the public to observe Expert Group deliberations, provide feedback, and view archives of all Expert Group communications.

public can observe EG deliberation on mailing list : And IRC channel #cdi-dev on freenode server.

Archive of mailing list is available on :

Please read to have more detail on the communication channel and how to provide feedback.

2.19 What is the URL of the Issue Tracker that the public can read, and how does the public log issues in the Issue Tracker?

2.20 Please provide the location of the publicly accessible document archive you have created for the Expert Group.

Section 3: Contributions

3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.

Contexts and Dpendency Injection for the Java EE platform 1.1 (CDI 1.1) Specification:

Java(TM) Platform, Enterprise Edition 7 (Java EE 7) Specification:

Apache DeltaSpike CDI extension project which contains ideas that could be standardized in CDI 2.0:

3.2 Explanation of how these items might be used as a starting point for the work.

These specifications will be the starting point for this work