Contexts & Dependency Injection for Java

What's in CDI 2.0 JSR proposal?

Posted by Antoine Sabot-Durand on Jul 28, 2014 | Comments

A few days ago, we submitted the official proposal for CDI 2.0. This new version is focused on 2 main goal:

  1. Adding Java SE support to CDI

  2. Add modularity to CDI to ease its integration with other specification or framework.

Off course a lot of feature and enhancement will come from this 2 goals and we’ll add a few more if possible. Let’s check what’s on the menu.

A new name

Not the most important part, but as we plan supporting Java SE, we slightly changed the name of the specification. Previously, the full name of CDI was: Contexts and Dependency Injection for Java EE. The proposed new name is: Contexts and Dependency Injection for Java. So to SE we go ;).

New features and enhancement proposed

Beyond the two main points introduced above (or because of them), we have the following features in mind

Identify the Java EE part in CDI

We have a lot of work to prepare the Java SE support in CDI. The first will be to check what’s is pure CDI and what’s is link to Java EE. So for CDI 2.0, The specification and TCK require a significant overhaul to be split into two parts.

  1. Part 1: The core CDI programming model (usable in EE and SE as well)

  2. Part 2: Java EE integrations for CDI (i.e. all the feature that won’t be available when working in Java SE).

Some of the splitting is straight forward (thre’s no EJB in Java SE), other could bring some discussion and extra work (do we want to support @Transactional in Java SE and how?).

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. To add support for Java SE, we really need such an API. Additionally, we would like to introduce a programmatic API for binding beans, allowing much greater flexibility for portably wiring a container.

Enhance the CDI context model

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.

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. For instance JAX-RS asked if it was possible to only have only the event part of CDI. Other discussion with the future java config specification are dealing with a "type discovery" part. One of the most asked module is a lightweight container, which takes the annotations specified by the @Inject specification, defines the behavior 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.

Other features

Off course there’ll be other features introduced in CDI 2.0. They come from

  1. Standardization of existing extension like the ones created in Apache Deltaspike project

  2. Request from our CDI 2.0 survey which will close on july 31st

  3. Features coming from other Java EE 8 spec, like @Transactional was introduced in CDI 1.1 after it was extracted from EJB spec.

Next Step

The proposal is being discussed among JCP executive committee members and if everything goes well it should be accepted in the coming days. At this moment we’ll start forming the CDI 2.0 Expert Group and begin effective work around this specification. We hope deliver the final spec in Q4 2015 or Q1 2016. Stay tuned on this blog or on @cdispec to have fresh news regarding the spec and the coming expert group.

CDI 1.2 released

Posted by Antoine Sabot-Durand on Apr 14, 2014 | Comments

After one year of existence, the CDI 1.1 specification is updated by a maintenance release. This maintenance review known as CDI 1.2 was adopted by the JCP with 24 yes and one Expert Member forgetting to vote. The minor increment (from 1.1 to 1.2) instead of a 1.1-SP1 is due to the the fact that we changed the javadoc and the TCK but beyond that there are far less changes from 1.1 to 1.2 than from 1.0 to 1.1. That’s being said, CDI 1.2 brings a lot of clarifications and small behavior changes. Let’s check what’s on the menu.

Major changes

Some of these changes are only big clarifications but some other have an impact on the implementations (these last ones have an asterisk in their title below). In order to use them you’ll have to grab a CDI 1.2 implementation (more info at the end of this post).

Rethinking the default bean discovery mode *

The default bean discovery mode (annotated) that allows CDI to be activated by default in Java EE 7 without beans.xml, file was the root of a lot of issues with other frameworks implementing the AtInject specification (JSR-330) or with libraries thought to be used with such frameworks. To solve these issues we changed the set of Bean defining annotations (class annotations that make a class an implicit bean candidate) :

  • all pseudo scopes annotations except @Dependent were removed,

  • @Interceptor and @Decorator were added,

  • all stereotype annotations (annotations annotated with @Stereotype) were added.

Clarification of conversation resolution

Conversation resolution mechanism could bring conflicts with servlet spec as stated in CDI-411.

We clarified the fact that implementation should prevent these conflict during conversation resolution in conversation context lifecycle

Rework on event chapter

You think you know how event resolution works in CDI? If you gained this knowledge by a careful reading of chapter 10 of the specification, think again. This chapter had a lot of approximations and confusing mentions. It was reviewed and partly rewritten (and yes, @Any is totally useless for Event<> injection, event firing and observers resolution).

This chapter is worth the re-reading.

You can also check the diff, if you prefer.

BeanManager more permissive during initialization *

In CDI 1.1, some BeanManager methods couldn’t be called before the AfterDeploymentValidation was fired. A non portable behavior was tolerated to allow use of these in AfterBeanDiscovery observers. These brought confusing mention in specification and javadoc. We decided to standardized the non portable behavior (not a big deal since all implementations adopted it). So in CDI 1.2 the following BeanManager method can be called (with restrictions) in an AfterBeanDiscovery observer method:

  • getBeans(String),

  • getBeans(Type, Annotation…​),

  • getPassivationCapableBean(String)

  • resolve(Set),

  • resolveDecorators(Set, Annotation…​),

  • resolveInterceptors(InterceptionType, Annotation…​),

  • resolveObserverMethods(Object, Annotation…​),

  • validate(InjectionPoint).

more details on the diff

Clarification on container lifecycle event use

We clarified the fact these event should only be used during invocation of their observer methods. Check the diff of the whole 11.5 paragraph

Rework on the initialization phase parts

Description of initialization phase in chapter 11 & 12 was very messing. No chronological ordering of event fired by the container, missing events. For instance we forgot to speak with ProcessInjectionPoint and ProcessBeanAttributes and ProcessProducer was wrongly placed before ProcessBean in chapter 12. So if you’re planning to write portable extensions you should perhaps re-read chapter 12. Not yet a page turner but far more accurate than it use to be.

CDI API now officially supporting OSGi

We integrated all OSGi bundle information in CDI 1.2 api jar. So now it’ll be easier to use CDI in OSGi environment. Before that you had to grab a special OSGi release of CDI 1.1 to have the good bundle info in our META-INF/MANIFEST.MF.

More minor changes

You can check the change section of the spec to check the more minor changes we introduces in the spec. We also work on Javadoc to synchronize it with the specification by updating it or correcting the spec when api description were wrong.

Concrete stuff

You’ll find concrete raw and final data in the links below.

  • You’re interested by the release notes? it’s here.

  • You want to check the diff between CDI 1.1 spec and CDI 1.2 spec? You’ll find it there

  • You can’t wait to read this new spec, the Javadoc or use with the API or TCK? Go to our download page

  • You want to start coding in CDI 1.2? Good news reference implementation (Weld 2.2.0) is available and provide all that’s needed to be integrated to a Java EE 7 server. More information on Weld 2.2.0 announcement

Tag Cloud