Tech Chat: Gavin King on Contexts and Dependency Injection, Weld, Java EE 6
DZone spoke with Gavin King, JBoss Fellow at Red Hat, earlier this week to discuss the newly ratified JSR 299 (Contexts and Dependency Injection) specification as well as Java EE 6 (JSR 316), both of which passed their final approval ballots on Nov 30th, 2009. In this exclusive interview, Gavin describes the evolution of the CDI specification (formerly known as Web Beans) and describes some of its primary goals. He also talks about the several CDI implementations currently on the market, including JBoss' own Weld implementation, and also highlights some of the benefits of running Weld can inside a servlet container, or in a Java SE environment. Finally, Gavin previews what we can expect to see in Seam 3, and points out the vast improvements that have been made in JSF 2 -- he also encourages JSF skeptics to "take a second look."
The complete transcript of the interview has been provided below.
DZone: Gavin, can you describe what you've recently been working on at JBoss?
Gavin King: At the moment we're just wrapping up work on the CDI specification and on our implementation of that specification, which is called Weld. We're also [wrapping up] a lot of the old work we've been doing, contributions we've been making to the Java EE 6 specifications. So we're pretty excited at the moment to be on the cusp of really seeing a Java EE 6 web profile, and also getting Weld out there. We've got a bunch of people who've just started playing with Weld and are coming back and telling us a lot of interesting feedback about their experiences with it.
I've been spending a bit of time working with the community on the first release of Weld and our direction going forward.
DZone: What’s the primary goal of the CDI spec?
Gavin: The history of JSR 299 is that it was a JSR we proposed to take some of the ideas that we'd been working on in the Seam project and bring them back into the [Java] EE 6 platform. So some of the ideas from Seam have gone into various places. Some of them have gone into the JSF 2 specification. There were a few ideas that came out of the work we were doing there that have ended up in EJB 3.1, but I guess the most interesting things we were doing there have found their way into JSR 299.
Originally JSR 299 was called Web Beans, to emphasize its role in making the web technologies of Java EE 6 work better with the transactional access technologies. Originally, one of the key problems we wanted to solve was how can we build an application that uses JSF very easily together with technologies like EJB. So it was originally called Web Beans.
Obviously, ideas evolved along the way. Also, when various other members of the community, especially some of the other Java EE vendors, came along and looked at the actual content of the specification, they felt that the name Web Beans wasn't a very great description.
It over‑emphasized that this was a web technology, when if you actually look at CDI, it's actually something much more general than that. So after much discussion, the name of the spec ended up being changed to “Context and Dependency Injection."
I guess if you want to sit down and look at the spec today, what you're going to find is a spec that really emphasizes a programming model for building your applications, that helps you improve the structure of your application code. I wouldn't say much more than that. That's the goal of the specification.This is a goal that most developers have, whether they're working with web technologies, whether they're working with client‑side technologies, whether they're working in SE, whether they're working in Java EE, and the ideas that are in CDI are applicable across all those areas.
DZone: And how does Weld fit in?
Gavin: Weld is the reference implementation of JSR 299. I believe it's the first implementation that passes the TCK, which is hardly surprising since it was developed hand‑in‑hand with the TCK by Pete Muir and his team. And it's not the only implementation out there, there are at least two far advanced implementations of CDI to others.
Note: Weld 1.0.0 is included in AS 6.0.0.M1, which is available for download at JBoss.org [http://www.jboss.org/jbossas/] and will be a part of JBoss Enterprise Application Platform 6 when it is made available to JBoss customers.
Resin has what's apparently an excellent implementation called CanDI. And Apache are working on an implementation called Apache Open Web Beans. So there are already these three implementations out there and I know that there are people using them. I have friends who are using Resin's implementations very successfully and say it's great.
Obviously Weld's just been released. But I think one of the interesting things about building something like Weld as a reference implementation is that you kind of have a specification that you've put a lot of work into all the corner cases, you've got every little corner case ‑‑ especially in the CDI spec-- figured out.
In fact, the implementation was working from something which really spec’ed out everything, which really didn't have little holes of, "Well what happens in that case?" And because it had to be developed along with the TCK, we also had tests for all that.
Even though there are obviously some early bugs in Weld, it's actually for a 1.0 release, it's far more solid than you would expect to see, which is really cool.
DZone: Weld can run inside a servlet container as well as on Java SE 5. What are some of the possibilities that open up by running Weld on the client side, on the Java SE platform?
Gavin: I want to emphasize that we created CDI very much with the view to this being a piece of a platform. So CDI is not in itself a platform for running applications. It misses out on things like transaction management, integration with object relational mapping, because these are all things that in the Java EE environment are provided by other specifications, by other technologies. So CDI is a very focused spec. It basically gives you a backbone for running your business objects on and integrating with other technologies.
There are a couple of different ways, things that integration could mean there, but let's just say it provides the backbone for doing that.
So it is a piece of a platform, and the platform that we had very much in mind was Java EE 6. However, this spec is very, very careful to make clear which pieces of CDI represent integration with the Java EE 6 environment and which pieces of the technology are general and are available anywhere a CDI container runs.
So, for example, Weld is able to execute in Tomcat or in Jetty, and there it is able to integrate with Tomcat and Jetty to provide services like dependency injection interception. And obviously in those environments where, for whatever reason, Tomcat and Jetty don't provide transaction management and real solid integration with data access and things like that, there is room for a project like the Seam project to come along and provide those additional services as portable extensions.
So CDI includes a portable extension API which lets me write extension modules to the CDI architecture that will run against any CDI implantation in any environment which supports CDI. That's very exciting.
So even though the spec is focused upon one particular aspect, and even though it has also been built with EE 6 in mind, it is also general enough that you can take it together with a set of portable extensions and you can use it in other environments like a servlet engine.
One thing that has been especially interesting for me to see is the pure SE form running in a main method in a swing application that the guys have got going. And actually, that is really super‑easy to set up and it is really nice to actually be able to see all your dependency injection and everything working in a swing application or just in a 'Hello World' application. It's really nice. You get all these things like dependency injection, interceptors, decorators that you might be used to from a more enterprise architecture.
DZone: How will CDI and managed beans be used in the context of EJB? Doesn't CDI effectively elminate the need for an EJB component model, through the combined use of managed beans with POJOs?
Gavin: One of the things that caused a lot of discussion, at times quite heated discussion among those of us who are interested in the EE platform, was that early drafts of the CDI specification included a notion of what we called it a simple Web Bean. It was a Java class that could be injected, that could be intercepted. So it was a kind of a component which allowed you to take advantage of the CDI services while having a less restricted programming model than EJB without having the lifecycle of EJB, without having some of the more enterprise‑y -- if you will -- services, declarative transactions, asynchronicity timers that you find in EJB 3.1.
some other members of the EE community found this to be problematic, that
the CDI specification was kind of introducing its own component model
for EE. After much discussion, we actually ended up with a solution. We
came to an agreed solution that I think is a much better solution: which is that this definition of simple Web Bbean was kind of
abstracted out into a different separate specification called the
Managed beans specification.
and so now what we have in the EE platform is a base component model. that oOther component models, (for example, the Legacy JSF managed beans are a kind of managed bean, EJBs are a kind of managed bean, servlets in the future will be a kind of managed bean) .
We now have this base component model that other specifications can take, layer additional services, additional programming restrictions in the case of something like EJB. , But where you will have this commonly defined basic lifecycle, basic things like accessibility via JNDI, things like interception, dependency injection via CDI, so that specifications like CDI can define technical aspects like dependency injection in an orthogonal manner to other specifications.
So finally, we have kind of a unified component model in Java EE, which was really actually one of the critical things we wanted to get out of this whole process.
Coming back to your question of whether it makes EJB somewhat redundant, I would say no. In fact, it makes EJB much more attractive because it provides a graduated model to get to EJB. Now if you need to take advantage of some of the core services, especially new core stuff that is coming in EJB 3.1, you don't have to buy in from the very start to the EJB model for all your classes.
You can say, "Hey, on
this particular class I need to add a transaction requires new or I
need to make it an endpoint for asynchronous method invocations, or I
want it to have a calendar‑based timer." And then at that point, you
can add a couple of extra annotations onto your class and you get the
services of EJB. But you can easily take a class which was not written
as an EJB and add those extra annotations and you are done.
So I think that graduated programming model is much more attractive. Now, in EE 6, the truth is that there are still a couple of services which are only defined for EJBs, which could be generalized. For example, declarative transaction management. In fact, that is kind of the main one.
A lot of people like the idea of being able to manage transactions by entertaining methods of their process. And there is no really good reason why that functionality should be available only for EJBs rather than for other managed beans.
So my expectation is, and it's the direction that people agree on, is that things like that which are currently part of specifications which define a specific programming model, a specific restricted programming model like EJB, should be generalized. So I would expect to see in Java EE 7 that example to become one of those things which becomes generalized or managed beans.
However, there are still going to be use cases for EJB. EJB as an endpoint for invocations which are coming into the system still makes complete sense as a model for a synchronicity and time and all this stuff. It still makes perfect sense.
DZone: You colleague, Dan Allen describes JSF 2 as "Seam's other path to standardization." What are some of the new and interesting features in JSF 2 that encapsulate some of these innovations from Seam?
Gavin: First of all, I was
very involved in some of the earlier work on this, but I haven't been
involved recently in the JSF 2 specification process. But I will give
you a very brief rundown. First of all, JFS 2 is a far different beast
than JSF 1.2. There has been barely any part of JSF which hasn't
undergone massive improvements. So to begin with, the mechanism for
defining views in JSF, which had been kind of JSP, JSP is now being
pushed off to the side a bit, and the Expert Group has brought in
Facelets, which is a really excellent templating technology that was
developed by a guy called Jacob Hookom, into the standard, and that is
really fantastic. I think Facelets is by far the best templating engine
I have ever worked with. And that is how you define your views in JSF.
That has some fantastic templating functionality. JSF two 2 introduces a notion of composite components, which is basically where you can define a JSF component just by writing a little Facelets fragment. That dramatically improves the usability of JSF.
Secondly, obviously the old JSF managed beans model is also getting shoved a bit to the side by CDI. Now you have a much better model layer. So we have a completely different, much better view layer. We have a completely different, much better model layer.
Then, in addition, the basic backbone of JSF remains kind of the same foundation, but improved in all kinds of ways, in terms of performance as a new stateless lifecycle, in terms of defining components. That has been totally thoroughly refreshed. It is now much, much easier.
The issues a lot of developers wrestled with surrounding request lifecycles, especially for get requests, have been addressed. There is a very cool feature I have seen called Page Parameters/View Parameters that made the way in there that makes get requests much easier to handle.
And so, I think it's going to be a very different experience. I certainly hope it's going to be a very different experience. We will see what happens.
DZone: So people who were, I guess, disillusioned with the previous version of JSF should...
Gavin: ....should take a second look. Look, I think there are going to be people who will never like JSF. There are a lot of people who find the servlet or Struts style of action‑based frameworks, the only thing they can get their head around, the only thing that feels natural to them, and I think that folks like that are probably going to never like JSF. They're probably not going to like Wicket either. I’m not one of those folks. I really am a fan of this more fine‑grained event‑based architecture that you can find in something like JSF or Wicket. I just refuse to go back to an action‑based framework. I don't think it's a nice way to structure the code. I think a Front Controller is an awful pattern, so I'm not going back. And I think that people who tried JSF and found that conceptually and architecturally it seemed good, but then found, just in practice, there were gaps, they should definitely go back and try again.
DZone: Do you have a timeline for when we can expect JSR 299 to be ratified?
Gavin: It should be soon. It should be going to the vote very soon. We have submitted the final draft, and an RI, and the TCK. I think it is supposed to go to the vote, together with the rest of the EE technologies, and I haven't heard any announcement from Sun that they have submitted yet. So I am not quite sure precisely what is going on. It kind of is a bit of a black box so far.
Editor's Note: JSR 299 passed the final approval ballot on Nov 30th, 2009. The final results can be viewed here.
DZone: How can the community contribute to the evolution of CDI and Weld?
Gavin: First of all, obviously, the big thing is go out there and download, try this stuff out. Send us feedback about where you think there are gaps. We're going to do a maintenance release, which will probably include a couple of new things. We will certainly do a 1.1 release with a fairly short timeframe to cover any gaps that people find. Now I don't think that there are big gaps. This is a spec that took three years to write and has gone through so many levels of review that you wouldn't imagine. Being such a controversial specification, everybody has taken a shot at it. Everyone has tried to poke holes in it.
So we want to know what 1.1 should do. We want to know what the maintenance release should do. And we also want the community to help us develop a set of portable extensions for it, not just for Weld, but for all CDI implementations that will release as Seam 3.
In Seam 3 we have a new direction, it's a set of portable extensions that provides integration with CDI and other non‑standard, non‑platform, non‑JCP technologies, things like Wicket, things like integration with Spring, things like that.
And now that we're not dealing with the JSF issues, now that it seems not a core component engine anymore, it will be a set of portable extensions for CDI.
DZone: Gavin, on behalf of the Dzone Community, thank you so much for your time today. It was a real pleasure.
Gavin: Thank you.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)