New CDISource CDI Project
CDI would make a great dependency injection framework outside of the Java EE container.
Want the option of using CDI without Java EE 6? CDISource 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 developers.
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.