Getting people up to speed with using CDI in Java EE

New CDISource CDI Project

Jessica Thornsby

“CDI would make a great dependency injection framework outside of the Java EE container.”

Want the option of using CDI without Java EE 6?
is a new project that aims to make this possible. The
project aims to enable the use of CDI in a vendor neutral
environment, maximise the portability of code across CDI
implementations, and encourage the overall adoption of CDI. In this
interview, JAXenter finds out more about what CDISource hopes to
bring to the world of CDI, from project co-founder Andy Gibson.

JAXenter: Can you introduce us to your
recently-announced CDISource project?

Andy Gibson: The goal of CDISource is to
advocate and demonstrate the use of the Java Contexts and
Dependency Injection (CDI) framework. There is a great deal of
interest in CDI, and also in Java EE 6, but having written about
both of these topics over the last few years a lot of people still
find it inaccessible and difficult to get started. We also think
that CDI would make a great dependency injection framework outside
of the Java EE container so we are also looking at providing vendor
neutral ways to use CDI in Java SE. This includes looking at ways
to integrate CDI with other frameworks that are not part of the
Java EE spec. The project co-founders Rick Hightower, Rob Williams
and myself all felt that CDI has a lot of promise and want to work
on making it as useful as possible for ourselves and for other

JAXenter: What problems do you perceive with
Java EE? And how does CDISource try to rectify these?

Andy: The current version of Java EE is very
good and we aim to work alongside the different groups and vendors
working on Java EE and even write about CDI in Java EE. We think
one of the ways to grow the use of CDI is to show people how to
also use it in the frameworks they want to use it in rather than
confine them to the Java EE option. JPA is a great example and
wouldn’t have the support it has today if it was strictly confined
to working in Java EE containers only. Similarly, once you take CDI
out of the Java EE container it loses a lot of functionality and we
aim to try and fill those gaps with some support libraries. Making
the JPA comparison again, if you took JPA out of the container and
lost the functionality of transactions, you either wouldn’t use JPA
or someone would write something to provide transactions in JPA. We
are just doing the same thing for CDI, and hopefully long term most
of these issues will go away as Java EE evolves.

The other problem is a lack of information about Java EE, which
is still in recovery from the years of FUD which has been spread
long after its sins were rectified. Part of our goal is to work on
getting people up to speed with using CDI in Java EE.

Lastly, there are some issues with the different pieces of Java
EE integrating well together which hinders the out of the box
experience. Not only will we be looking at the solutions offered by
vendors like JBoss with Seam for how they cover some of those
issues, but we’ll also be looking to see what we can provide to
remedy those problems.

JAXenter: One of the goals of CDISource, is to
allow developers to use CDI without Java EE 6. What are the
benefits of using CDI in this way?

Andy: The biggest issue right now is
lightweight unit testing. While most developers don’t consider
themselves writing code for Java SE, this is where their tests run
and currently, there is no way to perform simple unit tests using
CDI beans. This is one of the issues that is very important to both
me and to Rob, having dealt with the issues in the past.

There are solutions for testing code in-container but these are
not fully mature yet even though they are getting there. The other
problem with these solutions is that they are more intrusive on
your testing code. One of our first goals is to write a lightweight
test runner that will support CDI scopes and injection right into
the test case with as little intrusion as possible. We are aiming
for something that lets you go from writing a test case to running
it in seconds like you would any test.

There is also an argument for using CDI code in the Java SE
environment, whether it be a utility that uses injection, or an
application that re-uses the CDI based libraries from a web
application. Dependency Injection helps us write better code, Java
SE applications need better code too and CDI is a great Dependency
Injection framework so why not work towards making it usable in
Java SE?

JAXenter: What are the next steps for the
CDISource project?

Andy: We have several tutorials and articles
planned, we are working on some maven archetypes and putting some
additional features into our libraries. We’re going to be looking
for feedback to see what people are interested in and what their
pain points are and see how we can address those.

comments powered by Disqus