CDI 2.0 aims to enhance the Contexts and Dependency Injection specification based on feedback from users and the expert group. Key planned features include modularity through sub-specifications to make parts of CDI independently usable, better support for Java SE environments outside of Java EE, and enhancements to events, AOP, the SPI, and contexts based on feedback. The CDI 2.0 specification process is open and the expert group welcomes community participation to help deliver additional features.
2. Antoine Sabot-Durand
Senior Software Engineer @Red Hat
Java & OSS :
CDI co-spec lead
CDI community development
Tech Lead on Agorava
@antoine_sd
3. Agenda
Flashback on CDI 1.0, 1.1 and 1.2
Gathering feedback for CDI 2.0
CDI 2.0 new features
CDI 2.0 needs you
4. CDI 2.0 started one month ago
JSR 365 was the first Java EE 8 JSR proposed and voted
Expert Group is still in formation
We have a lot of community momentum
All contribution are accepted
6. CDI Timeline
CDI 1.0 (Java EE 6)
CDI 1.1 (Java EE 7)
CDI 1.2 (1.1 MR)
CDI 2.0 Starts
Dec 2009 June 2013 Apr 2014 Sep 2014
CDI 2.0 released
2016
7. CDI 1.0 - December 2009
A well-defined lifecycle for stateful objects bound to lifecycle contexts, where the
set of contexts is extensible
A sophisticated, typesafe dependency injection mechanism, including the ability to
select dependencies at either development or deployment time, without verbose
configuration
The ability to decorate or to associate interceptors to objects with a typlsafve
approach
An event notification model
An SPI allowing portable extensions to integrate cleanly with the container
8. CDI 1.1 - April 2013
Add automatic enablement of CDI for beans with a scope annotation, and EJBs, in Java EE
Add more introspection with event, bean, Decorator and interceptor meta data
Ease access to bean manager from outside CDI with CDI class
Moved interceptor binding to interceptors spec, allowing for reuse by other specifications
Add global enablement of interceptors (see the Java Interceptors Specification 1.2), global enablement
of decorators and alternatives, using the @Priority annotation
Add scope activation and destruction callback events
Add AlterableContext allowing bean instances to be explicitly destroyed
Add Unmanaged allowing easy access to non-contexutal instances of beans
9. CDI 1.2 - April 2014
Clarification in the spec regarding:
CDI Lifecycle
Events
Reworking Bean defining annotation to avoid conflict with other JSR 330
frameworks
Clarification on conversation resolution
OSGi official support in the API
13. About this survey…
There was a survey before the survey
Between May 28th and June 30th
260 participants
3 « demography » question
20 new features to rate (from 1 to 5)
14. Who answered?
I'm a developer using CDI on my projects
I'm an advanced developer extending CDI on my projects
I'm developing a framework based on CDI
16. What are their usage?
Plain Java EE Servlet container Java SE
17. Results 1/2
Features from most to less wanted av. rating
Asynchronous method invocation 4,04
Add asynchronous event support * 4,00
@Startup for CDI 3,92
Bootstrapping the container outside Java EE * 3,90
AOP for produced or custom beans * 3,65
Mutable container at runtime * 3,62
Security support 3,61
Observers ordering * 3,53
Better event control 3,50
Enhance SPI to give better access to all metadata 3,41
18. Results 2/2
Feature from most to less wanted av. rating
Better EAR support 3,32
Helpers to manipulate and build CDI metadata 3,32
An easier way to create AnnotationLiteral (and TypeLiteral) 3,27
Context SPI easily pluggable by the container 3,24
Configuration file 3,17
CDI parts * 3,12
Enhance SPI to retrieve Bean from its instances 3,1
JMX support 3,07
Introduce CDI Lite. * 2,78
Aligment with portlet 3.0 2,02
21. Modularity
Provide sub specs in CDI (called parts) that can be used independently
Each part should have an implementation
22. Modularity - Why ?
We want to add new features to CDI without making it a bloated spec
Having parts will help CDI adoption. Third party won’t have to get the whole
spec if they don’t want to
23. Modularity - What parts ?
Right now we are thinking of 3 parts :
CDI Light : DI without events, contexts, AOP and SPI
Providing CDI for mobile / constrained platform
Events : bring the event bus out of DI
Full CDI
24. Modularity - challenges
Be sure of the parts - too much or not enough granularity
Having an RI and TCK for each part can become huge work
26. Java SE support - Why?
To provide a mean of building new stacks out of Java EE
To boost CDI adoption for Spec working already on Java SE
27. Java SE support - challenges
Extract “Java EE” features across the spec to create a chapter dedicated to it
Decide what existing SE support we standardise
Add SPI for CDI integration with other framework / spec
29. AOP enhancement
Support AOP on custom or produced bean
Improve interceptor chaining
Support AOP on inner calls
30. SPI and contexts enhancement
Better access to all meta data created by CDI
Provide a way to add bean at runtime
Contexts enhancement for third party Spec
Contexts not only based on thread approach
31. CDI 2.0 needs you
CDI 2.0 specification is open to everyone
Come on join us on the mailing list and IRC channel
All infos on http://cdi-spec.org or by following to @cdispec on twitter
The more we are the more we’ll deliver