Contexts & Dependency Injection for Java

CDI 2.0 Beta 1 is available

Posted by Antoine Sabot-Durand on Jan 05, 2017 | Comments

After more than 2 years of work CDI 2.0 is around the corner. Its feature list is now complete and Beta for RI (Weld 3.0 Beta1) is available for download. This post lists what’s included and give you some insight on the final release and what comes next

Give it a try

First, you may want to start testing the RI and discover the new API, all the resources are listed below:

  • You can browse the spec document in html or pdf

  • If you prefer Javadoc you can read it here

  • CDI 2.0 Beta API is available on Maven Central. You can also download the jar here

  • Last but not least, the reference implementation (Weld 3.0 Beta 1) is downloadable here and can be also be used from Maven

Major features included in CDI 2.0

This CDI 2.0 includes important changes for the platform.

A lot of other small feature will be delivered. Refer to the coming release notes to check them all.

Release agenda

If everything stays on track we should send the PFD (proposed final draft) with TCK and RI to the JCP soon.

If the JCP ballot is green, CDI 2.0 final could be released before end of February.

What’s next

Our release plan for CDI 2.0 has always been to deliver it before Java EE 8 to let other spec grab our new features and make the best out of them.

We are still considering to start working on CDI 2.1 to clarify or add the few features needed for Java EE 8 and beyond.

Stay tuned.

Meet CDI at Java One 2015

Posted by Antoine Sabot-Durand on Oct 23, 2015 | Comments

During Java One 2015, a lot of CDI related talks and event will happen. find most of them in this post

In this agenda you’ll find most of CDI related talk to help you prepare your schedule

Focus on EG talks

If you want to have the best of CDI overview in Java One, don’t miss these talks:

  • CDI 2.0: Whats in the Works? (monday 12:30, Cyril Magnin I): to learn about coming features in CDI 2.0

  • Apache DeltaSpike, the CDI Toolbox (monday 2:30, Cyril Magnin I): Discover Apache DeltaSpike, the heart of CDI Ecosystem

  • Advanced CDI in live coding (tuesday 8:30, Cyril Magnin II/II): learn the power of CDI portable extension to integrate your framework in CDI programming model

I’ll be available for you questions

You’ll find me at the Hackergarten Tuesday afternoon and wednesday morning to help you on CDI, answer your question or discuss the spec. You can even pass by just to say Hello aor bring me a beer, coffee ;).

Have a nice Java One Week.

Learn CDI spec with our TCK

Posted by Antoine Sabot-Durand on Oct 15, 2015 | Comments

Beyond being one of the few open source TCK around, CDI TCK is one of the easiest to get started with.

Now that we have released a new version of spec doc embedding TCK test, it’s easier than ever.

Learn what we did and how to use it.

CDI TCK for the dummies

TCK stands for Technology Compatibility Kit. It’s one of the 3 part a JSR expert group has to release (2 others being the spec and the Reference Implementation).

A TCK is a collection of tests that actively define the spec. It’s the tool that is used to determine if an implementation is a CDI implementation or not. So this piece of code is the most important and the hardest to develop and maintain. Ok, RI could seem more important, but it’s under the spotlight and is nothing without the TCK.

To make short, TCK is the code that makes CDI a specification and thus a standard.

The great guy behind our TCK is Tomas Remes and he doing an awesome job pointing holes or unclear statements in spec text or refactoring all the TCK after CDI split in 2.0-EDR1.

If you want to learn more about the TCK I suggest that you check our dedicated page.

TCK is more than what it seems

The TCK role is not restricted to the specification mold, it can also be a great way to learn the spec by code. To crown that, thanks to Arquillian, CDI TCK is very easy to understand and very expressive.

But jumping from specification to test can be a bit complicated and this exercise can discourage many of our user.

That’s why, a few months ago, we started to think about a solution to create links from the spec text to the TCK.

It seemed quite doable since the reverse link has always existed: each since TCK tests have meta data about the spec section it refers.

So, Tomas made the required upgrade to the TCK and developed a script to add tests to the spec.

Meet Spec doc with TCK assertion

Don’t worry the original specifications docs stay unchanged, we only released a new flavor for them on our download page.

Due to normalization constraint (rules duplication avoidance) we have on the spec, some statement could seem confusing when reading them.

Let’s take, for instance, the first statement of section 3.15 Unproxyable bean types:

The container uses proxies to provide certain functionality. Certain legal bean types cannot be proxied by the container:

  • classes which don’t have a non-private constructor with no parameters,

Yeah a triple negation…​

You could take the next minute to figure out the exact meaning of the sentence or you could click on the "Show TCK assertions" link and check the two tests related to this section to see the cases where this rules make the deployment fails.

Learn, test and challenge

Now that you have this nice tool in your hand, TCK will be your CDI Lab, and perhaps, you’ll come back with corner use cases not covered or new challenges for the TCK.

Go and learn!

CDI 2.0 Second Face to face meeting feedback

Posted by Antoine Sabot-Durand on Sep 29, 2015 | Comments

Last week we had our second CDI 2.0 Face to Face meeting in Paris (France). This is a summary of the point discussed and leads we’d like to follow. Of course each point we’ll lead to a proposal later and discussed on the mailing list.

Roadmap

CDI 2.0 is still planned for 1st half 2016. We’ll focus on new feature and SE support for this release.

CDI 2.1 should start after 2.0 release and focus Java EE 8 specific enhancement. We’ll probably focus a bit more on modularity since Java 9 will be around the corner giving us a better visibility of how anticipate its new module approach. Content of 2.1 will be defined in the coming weeks

CDI SE review

CDI bootstrap on Java SE is one of the feature released in our first early draft. The Java SE support needed extra work to be complete and we wanted to review the boot api included to see how it could be enhanced.

bootstrap API

We’d like to review the proposed bootstrap API to make it a bit richer and have the boot process in a specific class. The idea is to get inspiration from the new Weld Se bootstrap with a builder pattern (see Weld and WeldContainer classes) and the possibility to explicitly choose the implementation if multiple impl should be in classpath.

Context control

This feature seemed a bit risky to specify. We’d preferred an approach based on existing built-in scope: RequestScoped and an interceptor activating it for a given invocation and unactivating it just after . something like this:

@WithinRequest
public void doSomethigWithRequestScopedBeans() {
}

This could give users the possibility to start and stop a context without explicitly adding these methods in the SPI We also discussed the possibility to have a Conversation-like context activated thru a built-in scope.

Bean discovery mode

The new bootstrap api should prevent us to specify a new bean discovery mode since the builder api will contains a mean to deactivate bean discovery and create a synthetic bean archive by adding class and packages of beans.

Async event review

There was discussion about exceptions handling and the issues raised from mixing sync and async observers. So the leads we’d like to follow are the following

  • stop calling sync observer from fireAsync() (fire() is for @Observes and fireAsync() is for @ObservesAsync)

  • Remove FireAsyncException in favor of CompletionException since an exception during async events pipeline execution is noting more than that.

To sum it up:

Table 1. async and sync events rules
Event method @Observes notified @ObservesAsync notified

fire()

yes, in the same thread

no

fireAsync()

no

yes, in a different thread

CDI Lite

As you know, CDI lite is one of the expected features for CDI 2.0. Yet, adding it with the SE / EE split for 2.0 could bring a lot of glitches and could reveal itself a catastrophe without speaking of specific impl and TCK for it.

That’s why we choose to add it in the annexe of the spec as a proposal for a next CDI version. Implementation will be allowed to create their CDI lite version based on this subset of CDI features:

  • JSR 330 with CDI type resolution rules

  • CDI qualifiers usage

  • Producers and disposers

  • Programmatic lookup

  • @Singleton and @Dependent pseudo-scopes support

  • SE bootstrap

We choose not to include events and spi to keep the impl lite. Of course this could be change during our discussion.

AOP on producer and custom beans

The goal was to propose a solution to apply Interceptors and Decorators on produced beans or custom beans. For producers we also have the problem of applying interceptor binding only on some method and not on the whole class. We looked for a solution that could be used in both case and that was more an "advanced users" approach than an out of box one.

The idea is to provide a class or a built-in bean to help produced bean instances using AnnotatedType to allow override of annotation on instance class. This suppose the addition of AnnotatedTypeBuilder to the SPI to ease the use of building a synthetic AnnotatedType. This would follow the same idea than the Unmanaged class which provide a way to inject bean in a non bean (non managed) class.

That would give something like:

public class MyAdvancedProducerBean {

    public BeanInstanceBuilder<MyClass> bib = new BeanInstanceBuilder<>();

    @Produces
    @RequestScoped
    public MyClass produceTransactionalMyClass() {

        AnnotatedTypeBuilder<MyClass> atb = new AnnotatedTypeBuilder<>()
           .readFrom(MyClass.class)
           .addToMethod(MyClass.class.getMethod("performInTransaction")
            , new TransactionalLiteral());

        return bib.readFromType(atb.build())
            .build(); //instance of the bean with requested interceptors / decorators
    }

    public void disposeMyClass (@Disposes Myclass td) {

        bib.dispose(td);
    }

}

A similar mechanism could be used in the create() method of custom beans.

Conclusion

Of course, all these points will be described in more detail in coming proposal documents. You’ll only find here general ideas of what we like to propose.

We also worked on other points in Jira for clarification or fix. This will go to the mailing list.

This post will be updated with new information or clarification if needed.

CDI 2.0 Early Draft Review 1 released

Posted by Antoine Sabot-Durand on Jul 03, 2015 | Comments

After eight months of work, the CDI 2.0 expert group is pleased to release this first draft of CDI 2.0 specification for community review. This draft contains important and long awaited features that will change CDI as we know it.

But these features are still proposals and we really need your feedback to know if the way we specified them fits your needs. Let’s check what’s on the menu.

CDI runs now in Java SE

One of the oldest request was the support of Java SE in CDI. Since the beginning the two main implementations (JBoss Weld and Apache OpenWebBeans) proposed proprietary solutions to use CDI in Java SE.

Then, Apache DeltaSpike came in and provided an absract solution to boot either implementations, but this wasn’t never standardized at spec level, until now…​

Why this important?

So, if implementation and a third party project already provide this Java SE support, what’s the big deal to have it at spec level? The answer is "increase adoption by other specifications".

A lot of Java EE specification provide a Java SE support (like JPA or JAX-RS). Since CDI doesn’t provide this support as well, they can’t rely totally on it since it is not available in Java SE. So, the side effect of this new Java SE support will be a better CDI integration in Java EE. If we add to this a broader adoption by third parties framework, we see that the benefits for CDI and its users goes far beyond the simple feature.

Preparing Java SE support (API split)

Adding such a straight forward feature to CDI seems quite easy on paper but, trust me, it wasn’t.

If you check the current 1.2 specification, you’ll see that EJB is everywhere in the spec. You also have reference to JSF, servlet or Expression Language all accross the document.

So the first work was to split the spec to put he Java EE specific feature in a dedicated part to have all CDI core feature (no tie to other spec) in its own part. This specification has now 3 parts plus an introduction as explain in the foreword section.

This work was done as carefully as possible to avoid destroying, duplicating or modifying rules, yet, your double check here is most welcome to be sure that we didn’t forget something in the rewriting.

Yes it’s rather long work to read (or re-read) the whole specification but it’s also the ocasion to see it with a fresh eye with this new organisation. You migh want grab the pdf version (whose look has been updated) of the spec to go through it.

Booting CDI in Java SE

After all this work (invisible for end users), we introduced the Java SE support by adding a bootstrap API for Java SE. The solution make use of already existing CDIProvider interface and CDI class.

Code for booting CDI in Java SE looks like this:

public static void main(String... args) {
    try(CDI<Object> cdi = CDI.getCDIProvider().initialize()) {
        // start the container, retrieve a bean and do work with it
        MyBean myBean = cdi.select(MyBean.class).get();
        myBean.doWork();
    }
    // shuts down automatically after the try with resources block.
}

Go check the Bootstrapping a CDI container in Java SE chapter in the specification and tell us what do you think.

Still work to do

Java SE support needs more work and we are still working on the feature. The two main aspect are:

Again, your feedback and ideas are most welcome to help us for these part specification.

Ordering event observers

One of the oldest requested feature for CDI was resolved in this EDR : observer ordering.

The feature was simply design by using @Priority annotation (from commons annotation) and will be used like this:

void afterLogin(@Observes @Priority(APPLICATION) LoggedInEvent event) { ... }

The use of @Priority was rather obvious since we already use this annotaion for interceptor, decorator or alternatives activation and ordering. The only issue here is that the annotation only targets types right now. We asked for a review of JSR-250 to add parameter as accepted target for @Priority.

Check the section dealing with observer ordering to have all the details.

Asynchronous events

Another important feature requested by many of you. Introducing Asynchronous event wasn’t an easy thing, because we needed to keep backward compatibilty with existing events. We also wanted to leverage new asynchronous API in Java 8 to provide the most up to date approach in the spec.

The solution we choose was to introduce @ObservesAsync and add methods fireAsync() in the Event interface. So the exisitng observer (defined with @Observes) will stay synhcronous and new observer defined by @ObservesAsync will be called asynchronously if the event was triggered with fireAsync() (and won’t be called from a classical fire()).

So asynchronous event usage will look like this:

@Inject Event<LoggedInEvent> loggedInEvent;

public void login() {
    ...
    loggedInEvent.fireAsync( new LoggedInEvent(user) );
}

...

public void asyncAfterLogin(@ObservesAsync LoggedInEvent event) { ... }

The best is to re-read all the event chapter in the spec to get the details.

Why this double activation is needed?

For the producer (fire()) side it’s rather obvious : we cannot magically change all synchronous event call to async. We need an handle on the work in progress (so a new method signature with CompletionStage), the payload mutation mechanism would break as all transactional events. So there’s no debate on fireAsync().

On the observer side, the reason is for backward compatibility. CDI events are a great way to cross boundaries of our own code and activate unknown code at runtime in another module of the app (i.e. another jar) that we don’t own. This other code can be a framework, a code developed by an other team in a big project or a legacy jar that we don’t want to touch.

Imagine the following use cases (all code running on CDI 2)

  • I’m compiling in CDI 1.x and one of the Jar (framework for instance) already migrated to CDI 2.0 firing async event where it use to fire sync events. Without activation on the observer side, I have all the chance to see my observer break. And if I decide to upgrade to CDI 2.0 I must have a way to activate / deactivate async call on given observers

  • I’m compiling in CDI 2.0 but use jar1 in CDI 1.0 and jar2 in CDI 2.0 coming from other teams. jar2 and jar1 are old related pieces of code communicating the event. The guys in jar2 had time to migrate to CDI 2.0 and switch most fire() to fireAsync(). Observer in jar1 will be called asynchronously if the default is to have async activated for all observers.

These example looks like corner cases but the side effect will be that no framework developers will switch to fireAsync() for the sake of defensive programming. So async event would have a serious adoption problem withotu this double activation. More than that, as we are designing a Java EE specification we must be committed to backward compatibility and cannot change behavior of old code, like it would do if we chose to not have activation on observer side.

Other change, corrections and clarifications

You can check the release notes of this early draft to discover the more minor changes we also introduced in the spec.

Implementation and TCK

TCK team and JBoss Weld team are currently working hard to provide a Reference Implementation for this draft. You’ll be notified as soon as there’ll be released.

We need you

To go on on this Early draft, we really need your feedback. The review period will be launch in the coming days by the JCP and will run for 90 days. You can give your feedback in many way:

Thank you for helping us making CDI one of the best programming model for Java and Java EE.

Tag Cloud