Find JSRs
Submit this Search


Ad Banner
 
 
 
 

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

Stage Access Start Finish
JSR Review Ballot View results 12 Aug, 2014 25 Aug, 2014
JSR Review   28 Jul, 2014 11 Aug, 2014
Status: Active
JCP version in use: 2.9
Java Specification Participation Agreement version in use: 2.0


Description:
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 Communications
  Issue Tracking

Team

Specification Leads
Star Spec Lead Pete Muir RedHat
  Antoine Sabot-Durand RedHat
Expert Group
  John Ament Credit Suisse
: Anatole Tresch
Antonio Goncalves
  IBM
: David Currie
Thorben Janssen JUG Chennai
: Rajmahendra Hegde
  Werner Keil Oracle
: Joseph Snyder
Mark Paluch
  Paumard, Jose RedHat
: George Gastaldi
RedHat
: Pete Muir
  RedHat
: Antoine Sabot-Durand
Santana, Otavio SERLI
: Florent BENOIT
  Mark Struberg Tomitribe
: David Blevins

Original Java Specification Request (JSR)

Identification | Request | Contributions

Section 1. Identification

Submitting Member: RedHat

Name of Contact Person: Antoine Sabot-Durand

E-Mail Address: asd@redhat.com

Telephone Number: +33 608 553 426

Fax Number: +33957700120


Specification Lead: Pete Muir, Antoine Sabot-Durand

E-Mail Address: pmuir@redhat.com, asd@redhat.com

Telephone Number: +447769557110, +33 608 553 426

Fax Number: -, +33957700120


Initial Expert Group Membership:

RedHat

Supporting this JSR:

Oracle
IBM
SERLI
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?

No

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

No

2.10 Are there any internationalization or localization issues?

No

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

No

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 (https://lists.jboss.org/mailman/listinfo/cdi-dev), 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 https://issues.jboss.org/browse/CDI.

We have a public EG discussion list at https://lists.jboss.org/mailman/listinfo/cdi-dev 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).

N/A

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 (https://jcp.org/aboutJava/communityprocess/speclead/final-license.txt)
* The RI and TCK will be licensed via the Apache License 2.0 (http://www.apache.org/licenses/LICENSE-2.0.html)

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 :

https://lists.jboss.org/mailman/listinfo/cdi-dev And IRC channel #cdi-dev on freenode server.

Archive of mailing list is available on : http://lists.jboss.org/pipermail/cdi-dev/

Please read http://www.cdi-spec.org/contribute/ 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?

https://issues.jboss.org/browse/CDI

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

http://docs.jboss.org/cdi/spec





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: http://jcp.org/en/jsr/detail?id=346

Java(TM) Platform, Enterprise Edition 7 (Java EE 7) Specification: http://jcp.org/en/jsr/detail?id=342

Apache DeltaSpike CDI extension project which contains ideas that could be standardized in CDI 2.0: http://deltaspike.apache.org/

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