The path to CDI 2.0@antoine_sd

Antoine Sabot-DurandSenior Software Engineer @Red Hat

Java & OSS :

CDI co-spec lead

CDI community development

Tech Lead on Agorava

@antoine_sd

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

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

Previously on CDI

CDI Timeline

Dec 2009 June 2013 Apr 2014 Sep 2014

CDI 1.0

(Jav

a EE

6)

CDI 1.1

(Jav

a EE

7)

CDI 1.2

(1.1 M

R)

CDI 2.0

Star

ts

2016

CDI 2.0

relea

sed

CDI 1.0 - December 2009A 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

CDI 1.1 - April 2013Add 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

CDI 1.2 - April 2014Clarification 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

Gathering feedback for CDI 2.0

Different sources

Survey

Jira requests

Other specs feedback

Former EG Feedback

CDI 2.0 survey

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)

Who answered?I'm a developer using CDI on my projectsI'm an advanced developer extending CDI on my projectsI'm developing a framework based on CDI

CDI version they’re usingCDI 1.0 CDI 1.1 CDI 1.2

What are their usage?Plain Java EE Servlet container Java SE

Results 1/2Features 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

Results 2/2Feature 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

CDI 2.0 new features

ModularityProvide sub specs in CDI (called parts) that can be used independently

Each part should have an implementation

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

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

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

Java SE supportusing CDI outside Java EE

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

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

Enhancing events

Asynchronous events

Event ordering

Event Range (war, ear, server, cluster)

AOP enhancement

Support AOP on custom or produced bean

Improve interceptor chaining

Support AOP on inner calls

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

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

Questions ?