CDI in Java SE

Abstract

It is probably evident by now that CDI provides many benefits for any nontrivial application, including applications that aren’t web-based. It may be surprising to find out that the CDI specification prior to version 2.0 officially only supported Java EE. Although Java SE was not officially supported, many CDI implementations did offer support for Java SE environments prior to the 2.0 specification. For example, both Weld and Apache OpenWebBeans offered support for Java SE. As the specification didn’t officially support Java SE, this meant that each container would need to provide their own nonstandardized API to allow the application to bootstrap and run the container. A major downside of having such nonstandardized APIs is that it makes it slightly harder for application developers to switch to another CDI container, as the code for bootstrapping the container in a Java SE environment would need to be rewritten. Libraries and frameworks such as Arquillian and Apache DeltaSpike Container Control do offer APIs that allow developers to bootstrap the CDI container, regardless of which container is actually in use. However, the primary focus of Arquillian is to be able to run unit and integration tests in different environments and is not as well suited to launching a CDI container within an application. Containers also need to be explicitly supported by Apache DeltaSpike Container Control. If a new container is introduced or a container changes its proprietary API in a noncompatible way, users of DeltaSpike Container Control need to wait for a new version to be released to support them.