 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 365: Contexts and Dependency Injection for JavaTM 2.0
The following changes have been made to the original proposal: 2015.07.28: 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: asd Telephone Number: +33 608 553 426 Fax Number: +33957700120 Specification Lead: E-Mail Address: Telephone Number: 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: RedHat Supporting this JSR: Oracle 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. 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. 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 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). 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) 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 |
