This series of articles introduces Contexts and Dependency Injection for Java EE (CDI), a key part of the Java EE 6 platform. Standardized via JSR 299, CDI is the de-facto API for comprehensive next-generation type-safe dependency injection as well as robust context management for Java EE. Led by Gavin King, JSR 299 aims to synthesize the best-of-breed features from solutions like Seam, Guice and Spring while adding many useful innovations of its own. In part 2 of this ongoing series we cover custom bean factories using producers/disposers, component naming and dynamically looking up beans.
Read Article - Dependency Injection in Java EE 6 - Part 2

What puzzles me is the fact that you declare in the using class the "name" of the object instance that must be injected. IMHO this is a form tightly-coupling. In this respect is much better spring-like xml config: 1 place where you decide which object is injected where and you can change configuration without recompile. But, OK, there is no end to the masochistic solutions people can devise Guido

What puzzles me is the fact that you declare in the using class the "name" of the object instance that must be injected.
IMHO this is a form tightly-coupling.
In this respect is much better spring-like xml config: 1 place where you decide which object is injected where and you can change configuration without recompile.
But, OK, there is no end to the masochistic solutions people can devise

Guido

Injection is done looking at the bean type and its qualifiers (but if you want you can use name too). This has a great advantage: it's type safe and toolable (without any plugin). Guido, what you call "configuration" is not real configuration. The fact that service B is injected into service A, never change between deployments. You don't need to edit XML on the fly (I could say that it's dangerous). When you setup bean dependencies you are programming, not configuring your application. I think that programming is better done in a type safe environment. Java is the right place, not XML. XML is good for many other things. Spring 2.5 already uses annotations. Spring 3 will use also more annotations. So, also respect to Spring, you are totally wrong in your statements.

The fact that service B is injected into service A, never change between deployments.

The problem is that **which** B instance is specified into A class (if I understand well). I don't mean to change on the fly (why is it a problem ?), but if, for instance, I want to use a mock B instance to debug some errors, I can easily change XML file without recompiling. Guido

The fact that service B is injected into service A, never change between deployments.

The problem is that **which** B instance is specified into A class (if I understand well).
I don't mean to change on the fly (why is it a problem ?), but if, for instance, I want to
use a mock B instance to debug some errors, I can easily change XML file without recompiling.

Guido

The same is true in CDI, but always in a type-safe manner. Give a look here: http://docs.jboss.org/weld/reference/1.0.0/en-US/html/injection.html#alternatives

Guido,

The same is true in CDI, but always in a type-safe manner.
Give a look here: http://docs.jboss.org/weld/reference/1.0.0/en-US/html/injection.html#alternatives

The only thing I would add here is that if you truly like doing all your object wiring in XML (mock object for testing aside), you can use CanDI XML like so: ${smtp.port} ${smtp.host} I do have to say though, I believe you might be in the minority in espousing the XML-centric approach to wiring dependencies. Personally, that is what I disliked most about Spring 2.0 - maintaining reams of XML files outside Java code that hardly ever changed outside of perhaps unit tests (BTW the testing dependency override case is precisely what @Alternative is designed for and is perhaps better-suited to these purposes if you take a closer look). Hope it helps, Reza

The same is true in CDI, but always in a type-safe manner.

I think it is indeed strange, that we are now using Annotation chiefly for something they were not derived for. People were pleading that it was not a programming feature, it was nothing like C pragmas, that it would be chiefly used on the source code level and so on. Now, it turns out that it is chiefly used at runtime and that we mainly use it for something that could be done with a standardized mere lookup method anywhere in the sourcecode. I think the benefit from these developments is rather thin and in particular, to a certian extent, it is quite orthogonal to what IoC was originally derived to be: A clean means of separation of Interface and Implementation (we do not do interfaces anymore..), and has turned into some strange way of (ab)using the new operator. And please do not tell me about contexts: Nothing here that a trivial factory class using generic would not do equally well. Additionally, I find it rather awkward that a lot of the JEE annotations require a "container" to work. I think from a fundamental perspective this is neither required not desirable (and I know of course that the specification team is working on it).

Now, it turns out that it is chiefly used at runtime and that we mainly use it for something that could be done with a standardized mere lookup method anywhere in the sourcecode.

Eh? Show us this standardized lookup method with its syntax. Let's see if it's better or worse then @Inject Service service;

I think the benefit from these developments is rather thin and in particular, to a certian extent, it is quite orthogonal to what IoC was originally derived to be: A clean means of separation of Interface and Implementation (we do not do interfaces anymore..), and has turned into some strange way of (ab)using the new operator.

Sure. Guice, Spring, Seam. All these frameworks provide thin benefits. This is the reason of their poor adoption.

And please do not tell me about contexts: Nothing here that a trivial factory class using generic would not do equally well.

You are right. In an hello world application with one or two beans, probably a trivial factory class would do equally well. I don't think you gave a decent look to JSR-299.

Sure. Guice, Spring, Seam. All these frameworks provide thin benefits. This is the reason of their poor adoption.

Spring adoption has been strong for years now, with or without annotations. Guice adoption is strong chiefly because it allows to do a lot of things without a container that JEE needs the container for. Annotations have fairly little to do with it. If you could put @Transactional oder @Datasource Kind of transactions into a single line of Java Sourcecode, the adoption would not be less. Why would it be, if the result is functional equivalent.

You are right. In an hello world application with one or two beans, probably a trivial factory class would do equally well.

I don't think you gave a decent look to JSR-299.

I did and I was not impressed. Anyway, there is very little difference between calling datasource.getConnection to factory.datasource().getConnection in particular as long as the name of the datasource/entity unit/something else is fixed in the source code for good and not bound to be overwritten! In fact in hyped languages like Scala even the Syntax can be identical.

Karl, With all due respect, I see "container vs. non-container" as another endless religious debate that has little to do with practicality. As I see it, an IoC container is a container too. In fact, the Resin application server is built around CanDI, our JSR 299 implementation. Perhaps you might be referring to heavyweight application servers like WebLogic and WebSphere vs. Tomcat? This is a straw-man argument IMO that highlights opposite extremes while ignoring the middle-ground. Resin has always been very lightweight and very performance-friendly. The same can be said of most open source Java application servers. This is certainly true with the Java EE 6 Web Profile, as Gavin pointed out in the recent thread on Spring 3.0. Hope it helps, Reza

Karl,

With all due respect, I see "container vs. non-container" as another endless religious debate that has little to do with practicality. As I see it, an IoC container is a container too.

Reza, what I want applications and libraries to do, is to be easily started "stand alone". I don't think that this is an esoteric requirement and ideally I want to run it in the same environment as the production runtime rather than in a mockup. If I need to start a "container", even an embedded one, to run basic unit tests, something is wrong IMHO. The Idea of a seamless IoC Container would than be that the container itself (if you want to call it that) is started IoC! Cheers, Karl

Karl, Not quite sure what you are getting at but if you are saying you prefer factory methods over DI containers you are of course free to do so. I think what you will wind up with is a home-brewed DI container that lacks all the features that build upon basic IoC functionality (and that's a whole lot more than just scope/context management for most modern DI containers). As to XML as a way of putting together a Java application, I think that's always been a poor fit in the name of misplaced notions of "loose-coupling" beyond what Java already offers. Anyways, you can do so with CDI if you really buy into it that much as I stated (although I personally think the trend going forward is quite in the reverse - just take a look at most Guice, Seam or Spring 2.5+ projects starting from a green field and don't have a lot of legacy code). Cheers, Reza

Karl,

Not quite sure what you are getting at but if you are saying you prefer factory methods over DI containers you are of course free to do so. I think what you will wind up with is a home-brewed DI container that lacks all the features that build upon basic IoC functionality

Interestingly enough you state that I end of with a DI container that lacks IoC functionality. IoC is DI and vice versa for me. Different name for the same thing. I think what you are really saying is I would end up with a system that does not contain any directives in source code, like an annotation called "@Transactional". Such an annotation does not build upon "IoC" but usually on "AOP" where the transaction is the cross cutting concern. There is NOTHING inverted here! And yes, in such a case I still would prefer to state the concern in an Aspect Oriented Language (I'd wish Java would be this language!) rather than an annotation.

Karl, Nicely put. http://sonymathew.blogspot.com

You don't need to edit XML on the fly (I could say that it's dangerous).

When you setup bean dependencies you are programming, not configuring your application. I think that programming is better done in a type safe environment. Java is the right place, not XML.

XML is good for many other things.

Nice... http://sonymathew.blogspot.com/

Completely agree. Dependency injection should be on instance level not type level. Lets say I have reusable interface I and two of its implementation of IImpl1 and IImple2. Now I have class C with getI(I i) and setI(I i). How with Annotation based DI I can create tow instances of C, one being set with IImpl1 and another with IImple2?

Completely agree.

Dependency injection should be on instance level not type level.

Lets say I have reusable interface I and two of its implementation of IImpl1 and IImple2. Now I have class C with getI(I i) and setI(I i). How with Annotation based DI I can create tow instances of C, one being set with IImpl1 and another with IImple2?

Please give a look to the spec before criticize. This is the "abc" of CDI. The options are: With names (usually not recommended): @Inject @Named Service service1; @Inject @Named Service service2; or with qualifiers (the recommended type safe way!): @Inject @S1 Service a; @Inject @S2 Service b; For deployment (test, production, etc..) specific injection, give a look to the "@Alternative" concept/annotation.

Are you suggesting to put both @Inject declaration into class C?

Someone is suggesting to read a spec to find out something obvious. Here is explanation of qualifiers that does not really make much sense. " @Inject public Client(@Synchronous PaymentProcessor syncPaymentProcessor, @Asynchronous PaymentProcessor asyncPaymentProcessor) { this.syncPaymentProcessor = syncPaymentProcessor; this.asyncPaymentProcessor = asyncPaymentProcessor; } ... Now, you may be thinking, "What's the different between using a qualifier and just specifying the exact implementation class you want?" It's important to understand that a qualifier is like an extension of the interface. It does not create a direct dependency to any particular implementation. There may be multiple alterative implementations of @Asynchronous PaymentProcessor!" The above tells me 2 nonsenses: 1. "That Your client class should decide for itself which implementation to use." Why? As a Client of PaymentProcessor I dont care what PaymentProcessor implementation I am going to use (that was the whole point of programing against interfaces). 2. "There may be multiple alterative implementations of @Asynchronous PaymentProcessor!". Who cares? Implementation of an interfaces is already its qualifier, why introduce annotation (oh, yea because everyone is now using them)? I can simply wire Asynchronous implementation of PaymentProcessor to my Client without any code changes to it.

I can simply wire Asynchronous implementation of PaymentProcessor to my Client without any code changes to it.

Synchronous and Asynchronous patterns DO affect how the client interacts with the service, and the client must be altered in most of the cases if the invocation pattern changes from synchronous to asynchronous.

I think the article I copied the text from is just using wrong example because java interface should be defined in asynchronous friendly way thus exposing some implementation details.

Tsolak,

I think the article I copied the text from is just using wrong example

Not sure exactly what article you are referring to, but it definitely seems like you have gotten to some strange conclusions on qualifiers. It's particularly puzzling since qualifiers have been in Java EE for quite a while now. Maybe your misconceptions stem from the fact that Spring does not support XML based qualifiers and relies on bean names in XML instead (just a blind guess - please don't read too much into it if it's not true)? All you need to do to switch implementations is change what class a qualifier is applied on - either via annotation or in XML as in the CanDI example I just posted. Hope it helps, Reza

With XML I dont hardcode Client code to any bean name. I Spring XML I can reuse my Client code and have different instances of Client class injected with different instances of its dependency. Can't do that with qualifiers unless I introduce multiple qualifiers and have the client to choose between them. Dont you agree that for this use case Annotations simply fail?

Tsolak,

Don't you agree that for this use case Annotations simply fail?

OK, I am going to ask you this for one final time - please read my posts and see if I've already addressed your concerns so that I'm not repeating myself over and over again. As I've already explained, you can use qualifiers in XML to support the relatively *obscure* case you are constructing. That certainly does not support the case that XML is what one should be using *all the time*. It's a little like saying we should always drive with four-wheel drive enabled just in case we might hit a rough patch on the road *although driving on four wheel drive uses almost twice as much gas*. In the cases where you need it, you can always use *XML as an override*. And once again, you can use names as "qualifiers" if that is what you really, really want to be doing and is more familiar to you from Spring XML. Hope it helps, Reza

Thanks for your comments Reza. For now I will better wait and see if Annotation based DI will be of much use.

Tsolak,

Thanks for your comments Reza.

For now I will better wait and see if Annotation based DI will be of much use.

Sure, no problems. If I can help in any way, that's my privilege. As I said already, I am sure there are some people who do genuinely find 100% XML configuration useful - that's why we bothered supporting it even though we don't encourage it or even like it ourselves. I don't know what your particular environment is, but I can honestly tell you that most people who work with annotations/Java 5 do not wish to go back to XML because of issues around verbosity, lack of type-safety and lack of tooling compared to IDE support for Java (XML just wasn't designed for wiring Object Oriented systems together after all). And that does include quite a bit of Spring users, which is why Spring is embracing annotations/Java config so quickly (the same as almost anyone else including the JUnit/TestNG guys). Anyways, no one is forcing anything on you after all. If something really does work for you and you are truly comfortable with it, why not just stick with it as long as you have your eye on alternatives (which you clearly do, otherwise why look at CDI/Java EE 6)... Cheers, Reza

Tsolak,

Thanks for your comments Reza.

For now I will better wait and see if Annotation based DI will be of much use.

Sure, no problems. If I can help in any way, that's my privilege.

As I said already, I am sure there are some people who do genuinely find 100% XML configuration useful - that's why we bothered supporting it even though we don't encourage it or even like it ourselves.

I don't know what your particular environment is, but I can honestly tell you that most people who work with annotations/Java 5 do not wish to go back to XML because of issues around verbosity, lack of type-safety and lack of tooling compared to IDE support for Java (XML just wasn't designed for wiring Object Oriented systems together after all). And that does include quite a bit of Spring users, which is why Spring is embracing annotations/Java config so quickly (the same as almost anyone else including the JUnit/TestNG guys).

Anyways, no one is forcing anything on you after all. If something really does work for you and you are truly comfortable with it, why not just stick with it as long as you have your eye on alternatives (which you clearly do, otherwise why look at CDI/Java EE 6)...

Cheers,
Reza

Don't know exactly what is your environment, but try to think about contexts where you have to extend someone else work Even if it is not you design style you must follow the established rules. And it is better to know what kind of monsters you have to fight in your next match. Guido

Guido,

And it is better to know what kind of monsters you have to fight in your next match.

Ummm..I think you are being way too defensive here and it is outside the parameters of rational or productive discussion. Let's please calm down and keep this friendly shall we? I've said consistently that the XML-centric view of the world is fine and is something we have built support for despite seeing it as an approach that is quickly loosing favor because of valid technical reasons (just look at what other people just said about DI and XML). And yes, that is based on broad observation and analysis of a pretty large variety of environments (not just mine but of almost the entire Java EE expert group membership - that's *hundreds* of people at very high levels whose job it is to keep an eye on these things :-)). I don't think that is something so horrible that we can't agree to disagree and leave it at that as gentlemen. And simply ignoring what someone bothered to post because you don't agree with it is very rude, I think... Peace, Reza

Guido,

And it is better to know what kind of monsters you have to fight in your next match.

Ummm..I think you are being way too defensive here and it is outside the parameters of rational or productive discussion. Let's please calm down and keep this friendly shall we?

I've said consistently that the XML-centric view of the world is fine and is something we have built support for despite seeing it as an approach that is quickly loosing favor because of valid technical reasons (just look at what other people just said about DI and XML). And yes, that is based on broad observation and analysis of a pretty large variety of environments (not just mine but of almost the entire Java EE expert group membership - that's *hundreds* of people at very high levels whose job it is to keep an eye on these things :-)).

I don't think that is something so horrible that we can't agree to disagree and leave it at that as gentlemen. And simply ignoring what someone bothered to post because you don't agree with it is very rude, I think...

Peace,
Reza

First of all, if you cut my post in this way it is hard to understand. When I say "you", I don't mean "you" Reza. It is a "you" in broader terms, so my post was a general discussion rather the a personal attack :-) It happens quite often to me to face with projects that are extensions of others work. Now, since the suggested way of using CDI is with annotations, it means the it is most likely to find projects where which injected object is, substantially, indicated in the receiving one and is, to me, not exactly the most desirable things to cope with (the monsters above). But, it seemed clear to me.... Guido

Guido, Very good - it seems like we are now in a position to return to logical discussion instead of things veering out of control. If you don't mind too much, I'll ignore your previous posts (I believe I and others have already sufficiently addressed them; feel free to let me know if they have not been addressed) and focus on the particular concern you have now - legacy code/pluggability. Rest assured, these are cases we have thought through and weighted (and still heavily favor annotations over XML for DI). Let's explore the case: 1. In most cases, you can simply inject existing objects using @Inject with no qualifiers involved (simply based on the type). You can even unit test these existing objects simply using @Alternative. 2. In the cases where you need to use a qualifier, if you have access to the existing source code, you can choose to simply place qualifiers on them where needed. All in all, you'll find that this is still less work than the XML based integration approach. 3. If you do not have access to the source code (let's call this the third-party library case), you can simply create object factories around these objects using producers/disposers as I've described in the article. I contend that the code will be more maintainable than going in the XML route. For example, this is what we are doing with the iBATIS pluggable extension to CDI. All you need to do as an API client is drop in a jar into your application and inject objects that you need like this: @Inject @SqlMapConfig(configLocation="sqlmap-config.xml") private SqlMapClient mapClient; You can of course create even more powerful integration mechanics using the CDI SPI (which I will discuss in a later article). 4. If you really feel XML is still the route for you, you are most certainly welcome use the XML support shown in my earlier example and simply place meta-data on your existing object via name-spaced, type-safe XML. After all, this is why we bothered building such support so you can use it when needed (but hopefully not otherwise). 5. Finally, just like the duplicate object definition case, this is really not a reason not to use annotations in your own, newly minted components and benefit from increased type safety, more concise syntax, improved readability and better tool support. 6. Pluggability for CDI code/modules is an central concern that a lot of thought has been put into already. I encourage you to read the modularity section of the CDI spec. I think you will find that modules written in CDI are a lot easier/more natural to integrate - and all in Java nonetheless! The iBATIs example above is hopefully indicative of that fact. 7. Now, I understand that you seem to feel strongly about keeping all injection meta-data out of Java code (the XML==loose coupling KoolAid has certainly been dispersed enough for people to buy into it), but do you see the point that using annotations is fundamentally different from coding to specific implementations? All you need to do in CDI/annotations to switch implementations is change an annotation on an interface, just as you would have to change our XML config (and probably have to recompile/redeploy anyway). I think the "mental block" you have here is that you don't see annotations as meta-data. That's certainly understandable if you do a lot of XML, but I don't think it's a mindset that is that ingrained once you begin to see how your application look like without volumes of XML and more like a plain Java application with just some annotations :-). This make more sense now? If not, we can by all means explore it further... Glad we could return to a more productive note on this :-). Cheers, Reza

Guido,

Very good - it seems like we are now in a position to return to logical discussion instead of things veering out of control...............Glad we could return to a more productive note on this :-).

Cheers,
Reza

Reza, thanks for your kind post but, believe me, I have never been elsewhere so there was/is no need for me to come back from some strange/wild place. It's a pity that you always try to put me on a bad light, but maybe it's me. Cheer, Guido

Guido,

It's a pity that you always try to put me on a bad light

I won't quote/analyze everything you've said on this thread, but you've used sarcasm, red herrings, straw man arguments, accused me of being intolerant/ignorant, made grossly negative comments about Java SE 5 engineers (who BTW I think did a great job), not to mention post over-the-top negative remarks on CDI developers that have all been addressed (starting with the choice language in your very first post). I don't think claiming that you were somehow wronged is very reasonable at this point... However, if you took offense at anything I said, I apologize. If it is any help in terms of understanding where I am coming from, one standard I personally try to maintain for myself on-line is not saying anything that I would not say in a professional setting, face-to-face (if you notice carefully that is pretty much what everyone else here is doing). I would also suggest taking a close look at the following (including the references): http://en.wikipedia.org/wiki/Netiquette. I certainly stop and think twice before posting anything over-the-top, negative or inflammatory (unless I feel the situation really calls for it)...why do it if the goal is to have a productive discussion? Peace, Reza

Guido,

It's a pity that you always try to put me on a bad light

I won't quote/analyze everything you've said on this thread, but you've used sarcasm, red herrings, straw man arguments, accused me of being intolerant/ignorant,

Really shocking, Reza. I don't want to end with clarifying private emails again. I began answering to your posts because a number of posters have simply observed the CDI by annotations has certain side effects and you answered repeatedly that we can use XML override. Well, no offence Reza, but what kind of answer is that ? Is it an authorization statement ? You have tagged the position in turn as :marginal, corner case, minority (btw, is this sarcasm from your POV or not?). I don't know if it is really so, but who cares ? This was not the point, and I think anyone participating in this thread has realized it.

made grossly negative comments about Java SE 5 engineers (who BTW I think did a great job),

OK, you think that auto-unboxing is the best thing after sliced bread.

not to mention post over-the-top negative remarks on CDI developers that have all been addressed (starting with the choice language in your very first post).

Please use google to find out that masochism is not a negative thing: it affects oneself and nobody else.

I don't think claiming that you were somehow wronged is very reasonable at this point...

However, if you took offense at anything I said, I apologize. If it is any help in terms of understanding where I am coming from, one standard I personally try to maintain for myself on-line is not saying anything that I would not say in a professional setting, face-to-face (if you notice carefully that is pretty much what everyone else here is doing).

OK, I have to guess that in a professional setting you use to tag as substantially wrong the observations of your peers instead of answering about the merit of the issues. It reminds me the typical answer when someone points out the side effects of dynamic proxies in certain popular ORMs: "you are wrong, if you use instanceof, yours is a bad design".

I would also suggest taking a close look at the following (including the references): http://en.wikipedia.org/wiki/Netiquette. I certainly stop and think twice before posting anything over-the-top, negative or inflammatory (unless I feel the situation really calls for it)...why do it if the goal is to have a productive discussion?

Peace,
Reza

Next time try to read twice too, if once is not enough, it might help to avoid to emotional answers. No peace, because there is no war. Only a lot of bitterness Guido

Guido,

Next time try to read twice too, if once is not enough, it might help to avoid to emotional answers. No peace, because there is no war. Only a lot of bitterness.

OK, this is getting way too over-dramatic/silly/Jerry Springer-ish. I'd rather not continue this particular exchange further, especially since I've already said all that is really worth saying on it from my perspective. Yet again, sorry if you took any offense. It's certainly not my intent to upset anyone - that's not why I bothered writing the article or try to make time to answer any follow-up constructive questions here. That being said, I do believe I have every right to speak my mind as long as it is done politely and professionally (which I believe I have). Like it or not, I do see heavily using XML for DI as being very problematic and steadily loosing favor in contrast to the Java/annotation based approach (like numerous other people). In case you've missed the point, I respect that you beg to differ. That's exactly why we support both models via CanDI. Let's kindly move on from this and stop insisting that we have to agree with each other (or rather that I must agree with you despite having good reasons to disagree). As you correctly pointed out, neither of us need external authorization to our respective views after all, right? Cheers, Reza

Tsolak,

Don't you agree that for this use case Annotations simply fail?

OK, I am going to ask you this for one final time - please read my posts and see if I've already addressed your concerns so that I'm not repeating myself over and over again.

As I've already explained, you can use qualifiers in XML to support the relatively *obscure* case you are constructing. That certainly does not support the case that XML is what one should be using *all the time*. It's a little like saying we should always drive with four-wheel drive enabled just in case we might hit a rough patch on the road *although driving on four wheel drive uses almost twice as much gas*. In the cases where you need it, you can always use *XML as an override*.

And once again, you can use names as "qualifiers" if that is what you really, really want to be doing and is more familiar to you from Spring XML.

Hope it helps,
Reza

Reza, I am not sure if you are deliberately missing the point. With pure annotation you must code in the client the directives for the injectable objects. Please, do not put XML on the table again. We already know the pros and cons. It has been told that annotations are not for configuration. Right, in fact the common use is: 1. Table names, column names and other similar stuff in ORMs 2. Endpoints in Web Services OK, but "DI is not configuration, is some sort of programming". Programming ? Isn't java lang enough ? I think that java is being overloaded by a lot of unuseful stuff since Java 5, conceived by questionable scientists. One for all is auto(un)boxing. Never got a NPE popping out from nowhere on an int assignement ? Guido

Tsolak, Did you read my previous posts? You can use XML with CDI if you really want, no one is stopping you from it. If you want to use Java instead of maintaining reams of external XML descriptors, qualifiers are really the way to go and there are good, solid reasons people are going that route... Please take a closer look at the example above, the client code *does not* determine what implementation in injected, *which implementation class you place the qualifier on does*. If you are more familiar with Spring, take a look at Spring @Autowired, it works on the same basic principle other than allowing pure name based resolution and not type. Hope it helps, Reza

You are suggesting to write Client against qualifier and interface (you do put qualifier annotation into Client code). All I want is to write it against interface only.

Tsolak,

All I want is to write it against interface only.

Yet again, please do us both a favor and kindly read my previous posts carefully. If you don't want to use a qualifier in Java code and just want an interface, you can use the XML example I just posted. Also, if you are that gung-ho about using names and don't like qualifiers "just because", you can use @Named as a qualifier as I described in the article in the same manner that you might be used to in Spring XML. To make it brain-dead simple, here is how a Java/annotation based example using @Named looks like: @Inject @Named("abcBean") ABCBean bean; Hope it helps, Reza

Tsolak,

Did you read my previous posts? You can use XML with CDI if you really want, no one is stopping you from it. If you want to use Java instead of maintaining reams of external XML descriptors, qualifiers are really the way to go and there are good, solid reasons people are going that route...

Please take a closer look at the example above, the client code *does not* determine what implementation in injected, *which implementation class you place the qualifier on does*. If you are more familiar with Spring, take a look at Spring @Autowired, it works on the same basic principle other than allowing pure name based resolution and not type.

Hope it helps,
Reza

Reza, we are not discussing the possibility to use XML (we know and, I think, it is not something that you have to repeat every time someone has a different point of view) but the fact that with annotations certain things cannot be achieved. Point. And they might be corner cases for your design style that, obviously is not the best in every use-case. It is just yours. (I don't care that this style is widely used, it is simply not mine because I think differently, nor worse nor better). I agree with Tsolak, it is crazy that the client must somehow give hints on the injected object other than the declaring class/interface of the member/method parameter. Guido

Tsolak,

I agree with Tsolak, it is crazy that the client must somehow give hints on the injected object other than the declaring class/interface of the member/method parameter.

Guido

This does cause some leakage of the implementation but doing so allows one to dispense with separate DI artifact. I guess if there was a strongly-typed DI Domain Specific Language, whose documents lived as a separate artifact, you could solve the problem of weak-typing and maintain loose coupling. But you still have to maintain the DI artifact (and somebody has to invent the DSL and create Plugins for the IDEs)

Tsolak, You can do what I think you are describing with the following CanDI XML: While XML is the way to solve some of these corner cases, I think it's a leap to go from there to saying it is preferable to the annotations/Java model wholesale that is a lot more type-safe, concise, maintainable and tool-friendly. After all, if you don't care about these things, why use Java at all :-)? Again, all that being said, if XML is what you prefer, so be it... Hope it helps, Reza

I am all for type safe and pure Java approach. Never liked configurations vi XML, but Annotation based Dependency Injection is simply inferior to XML based configuration. It would be much cleaner if we had Java class that would create and wire beans together. But I guess thats not cool since its just plain simple.

Tsolak,

Never liked configurations via XML, but Annotation based Dependency Injection is simply inferior to XML based configuration.

You are certainly entitled to that opinion. Personally, I think for a vast majority of cases, XML based configuration for applications makes simple things hard and hard things even harder. Wiring together dependent objects for most applications should certainly be as simple and as close to the code as possible.

It would be much cleaner if we had Java class that would create and wire beans together. But I guess that's not cool since its just plain simple.

Kindly take a careful read at my and other folks previous posts. Most modern DI containers have moved far past just as object factories that can be replicated easily in hand-written code. That being said, if that if really what you want, you could use CDI producers (or the newly introduced Java config facility in Spring if that's what you use) or not use a DI container at all if your application is really that simple... Cheers, Reza

The point of using DI is to make testing easier, by allowing the testing of most business logic outside any container. How does CDI help the developers achieve this? I mean if we cannot use these DI annotation outside JEE servers, exactly what values does CDI bring to developers?

Danny, Yes, we standardized embedded containers in Java EE 6 so that you might be able to test outside the application server. If you are familiar with Spring testing support (and I am going to guess that you are), the embedded container is essentially the same concept - it's a complete CDI capable runtime that can be started in a JUnit test for example. For Resin/CanDI, we've built specific integration support around the embedded container for JUnit and TestNG. Here is how that looks like: @RunWith(ResinJUnitRunner.class) // Deployment overrides for the test, if needed. @TestConfiguration(beanXML="beans-test.xml", ejbJar="ejb-jar-test.xml", persistenceXml="persistence-test.xml") // JUnit test. public class AccountServiceTest { // Inject via CDI into unit test. @Inject private AccountService accountService; @Test public void testGetAccount() throws Exception { Account account = accountService.getAccount(1007); assertNotNull(account); } } The JBoss guys are doing the same thing around Weld/Embedded JBoss as a portable extension. I think OpenWebBeans has similar plans as well. Hope it helps, Reza P.S.: Please take a look at the code carefully before asking the "usual suspect" questions along these lines. While I'm all for being there for the community, I think I deserve respect for my time/effort the same as anyone else...

Danny,

Yes, we standardized embedded containers in Java EE 6 so that you might be able to test outside the application server. If you are familiar with Spring testing support (and I am going to guess that you are), the embedded container is essentially the same concept - it's a complete CDI capable runtime that can be started in a JUnit test for example. For Resin/CanDI, we've built specific integration support around the embedded container for JUnit and TestNG. Here is how that looks like:


@RunWith(ResinJUnitRunner.class)
// Deployment overrides for the test, if needed.
@TestConfiguration(beanXML="beans-test.xml",
ejbJar="ejb-jar-test.xml",
persistenceXml="persistence-test.xml")
// JUnit test.
public class AccountServiceTest {

// Inject via CDI into unit test.
@Inject
private AccountService accountService;

@Test
public void testGetAccount() throws Exception {
Account account = accountService.getAccount(1007);
assertNotNull(account);
}
}


The JBoss guys are doing the same thing around Weld/Embedded JBoss as a portable extension. I think OpenWebBeans has similar plans as well.

Hope it helps,
Reza

Reza, nice work on this! Is this test framework available yet?

Jeremy,

Reza, nice work on this! Is this test framework available yet?

Sorry for the late reply on this - I had to catch up on a few things. Yes, the Resin embedded container and test framework is in our code-branch and early feedback is very welcome from folks like yourself. I'm not 100% sure where the JBoss guys are; I know they have a working code sample - the best thing to do is just to ask on the JBoss forums. Cheers, Reza

The point of using DI is to make testing easier

This claim wasn't substantiated in the past. Quite the contrary. Larger application can essentially become untestable (by UnitTests) because of DI.

DI can make Unit Testing easier by encouraging the use of interfaces, thereby enabling mocking. When over-used, however, DI can make Unit Testing (and development in general) harder because of the need to manage numerous, typically weakly-typed artifacts. My current projects, using Spring 2.5.x certainly fits this description. The team realizes the problem now and is rediscovering the beauty of using new() in situations that don't warrant the overhead of DI. For certain components (typically anything involving the network), DI does makes a lot of sense. Given that JEE6 with CDI strengthens typing and allows one to dispense with XML configuration, it certainly looks like a step in the right direction.

DI can make Unit Testing easier by encouraging the use of interfaces, thereby enabling mocking.

I don't buy this point. Mocking can be done with subclasses using stubbing. Mock libraries permit this. Interfaces are good for a clean design, when there is a real need for them.

When over-used, however, DI can make Unit Testing (and development in general) harder because of the need to manage numerous, typically weakly-typed artifacts.

First, usually a DI libraries provide junit or testng extension to test integration between components. Strict unit tests are not improved or get worse by DI, if DI is done over POJO (as in Seam, Guice, Spring, CDI...).

My current projects, using Spring 2.5.x certainly fits this description. The team realizes the problem now and is rediscovering the beauty of using new() in situations that don't warrant the overhead of DI. For certain components (typically anything involving the network), DI does makes a lot of sense.

Given that JEE6 with CDI strengthens typing and allows one to dispense with XML configuration, it certainly looks like a step in the right direction.

Can you explain better this issues? AFAIK Spring supports integration test quite well. Are you using its infrastructure or not?

Yes Spring offers lots of functionality for testing, be it of the Unit or Integration variety. This is used to various degrees by the members of the time. Still our JUnit tests are poorly maintained. One of the reasons is that earlier, now since departed members of the team, over-used DI (albeit with the best of intentions). Almost every class, no matter how small, was accessed through an interface and the whole thing was held together by endless amounts of XML config, the correctness of which was always uncertain until you deployed the entire application and ran the integration tests (in our case with SOAP-UI). For Unit Testing we duplicated large portions of the production DI config, changing the values where appropriate to reflect the testing environment. It often occured that somebody changed something in the production XML config and neglected to update the XML config for the unit testing, thereby breaking his colleagues Unit Test. My point concerning DI is really that it can be over-used. All tools and techniques come with tradeoffs. With DI you gain looser coupling but at the cost of maintaining the DI configuration, be it in the form of XML or Annotations. That is why nobody (not even the members of my team :o)) have ever proposed replacing Long or String through a service with dependency injection. So deciding where to use DI is a line-drawing exercise. Remote services are great candidates for DI but local bits of code, such as convertors between external and internal types are probably best created through constructors.

Still our JUnit tests are poorly maintained. One of the reasons is that earlier, now since departed members of the team, over-used DI

Exactly what I experienced in a project, including the departure of the 'gurus' who left behind the mess.

My point concerning DI is really that it can be over-used. All tools and techniques come with tradeoffs. With DI you gain looser coupling but at the cost of maintaining the DI configuration, be it in the form of XML or Annotations.

I agree that 'techniques come with tradeoffs'. But isn't 'looser coupling' nothing but another DI myth (besides better testability) that couldn't stand the test of time? The coupling is still there but it is less visible at compile time. Dependencies are hidden in XML or Annotations behind extra levels of indirection. Obvious coupling is replaced by convoluted coupling behind the scenes.

Still our JUnit tests are poorly maintained. One of the reasons is that earlier, now since departed members of the team, over-used DI

Exactly what I experienced in a project, including the departure of the 'gurus' who left behind the mess.

My point concerning DI is really that it can be over-used. All tools and techniques come with tradeoffs. With DI you gain looser coupling but at the cost of maintaining the DI configuration, be it in the form of XML or Annotations.

I agree that 'techniques come with tradeoffs'. But isn't 'looser coupling' nothing but another DI myth (besides better testability) that couldn't stand the test of time? The coupling is still there but it is less visible at compile time. Dependencies are hidden in XML or Annotations behind extra levels of indirection. Obvious coupling is replaced by convoluted coupling behind the scenes.

I am also critical of "loose-coupling" as end in itself. Tight-coupling can be had with less code and gives more clarity and is, I believe, the right choice in the vast majority of cases, else we wouldn't be using classes like String and Integer directly. As we all know in certain situations it makes sense to be able to "swap-out" an implementation, which means binding the client to a super-type and hiding the implementation behind it and then somehow making the correct implementation appear at the right situation. I suspect there is no way of doing this that will please everybody, although JEE6 with CDI does represent an improvement in the state of the art. All the approaches that I am aware can be measured by the following criteria: 1) type-safety 2) lines of code 3) number of artifacts 4) leakage of implementation details into the client The example provided for CDI appear very strong in the first three points at the expense of some leakage (point 4). Using Spring 2.5.x DI with XML provides a complete contrast. Here the type-safety is non-existent, the lines of code is fairly high due the need to maintain a separate XML Config but it has the advantage of providing a seemingly perfect separation between client, interface and implementation.

Eugene,

The example provided for CDI appear very strong in the first three points at the expense of some leakage.

This is an excellent way of describing exactly the trade-offs we made - a wholehearted bravo!! Most of us CDI guys just see an overzealous pursuit of "loose-coupling" as being valuable on its own right as wrong-headed. Cheers, Reza

Still our JUnit tests are poorly maintained. One of the reasons is that earlier, now since departed members of the team, over-used DI (albeit with the best of intentions).

I still fail to understand why DI is bad for your tests. I have experience in large EJB3 applications, where I can still perform integration test (using my onwn infrastructure) despite the use of @Ejb, @PersistenceContext annotations in the code. Could you show one small example of this DI weakness?

Still our JUnit tests are poorly maintained. One of the reasons is that earlier, now since departed members of the team, over-used DI (albeit with the best of intentions).

I still fail to understand why DI is bad for your tests. I have experience in large EJB3 applications, where I can still perform integration test (using my onwn infrastructure) despite the use of @Ejb, @PersistenceContext annotations in the code.

Could you show one small example of this DI weakness?

Our mistake with DI was using it in a fine-grained manner. To use an analogy, if an application was a horse, I'd recommend using DI to connect it to the saddle, the shoes and the rider. Whereas the connection between the muscles, the bone and the tendons should be direct since they belong together (unless you're modeling a butcher's shop). Because we used DI in a too fine-grained manner we had too much maintenance of the XML config, both for the production and the test environments. This made our entire development failure prone. At any one time only about 60% of our JUnit tests ran, although part of the problem was the large number of external interfaces, which were often off-line and difficult to mock in a meaningful way. More concretely, we have a fair amount of code for converting between external and internal types (the external types flow via Web Services to the GUII-Client). As is typical in software our types exhibit a lot of nesting (ex. a contract has 1..n persons, who each have 1..n accounts and so forth), so the contract convertor needs to use the person convertor who needs to use the account convertor...etc. With the best of intentions the developers initially separated each converter into an interface and let each convertor only see the interface of its peers, using Spring 2.5 DI to bring it together. We subsequently realized that this made little sense because we never mocked the convertors - they contained logic that behaved like true functions (i.e. completely predictable without side effects). In the case of the convertors we now dispense with interfaces and DI and connect the implementations to each other using new(). Sometime tight coupling is the better alternative. In the case of our convertor logic tight coupling results in fewer artifacts and improves clarity at the expense of flexibility that we didn't need. Now we think about the pros and cons of DI before using it. Before we didn't think about this critically, we simply believed that DI is a good thing so the more DI the better.

I still fail to understand why DI is bad for your tests.

DI (injection by configuration or auto-wiring) usually doesn't work for UnitTests. Instead you have to create an appropriate graph of dependent mock-objects and manually inject it to test your (Business-)objects.

I still fail to understand why DI is bad for your tests.

DI (injection by configuration or auto-wiring) usually doesn't work for UnitTests. Instead you have to create an appropriate graph of dependent mock-objects and manually inject it to test your (Business-)objects.

I can now understand the Eugene's point of view. But what you are saying is just not true, because usually a DI framework provide integration with testing frameworks, so that you can test beans and their dependecies. In real unit (not integration) tests the whole problem is also easier.

Eugene,

Given that JEE6 with CDI strengthens typing and allows one to dispense with XML configuration, it certainly looks like a step in the right direction.

Thanks for the kind words, that's definitely great to hear. We've tried our best to look at what is working and not working out there and standardized that (Gavin and the JBoss guys especially made an excellent effort). I think there's a lot of ideas that slowly need to be evolved out of enterprise Java, overuse/misuse of DI and over-dependence on/misuse of XML being a just few of them. The good thing I think is that the other DI framework see that too, I think. Cheers, Reza

over-dependence on/misuse of XML being a just few of them.

History actually says that any "new" feature is overused since developers have fascinations with trying 'something different', and so you can add "over-dependence on/misuse of annotations" to that list of yours. It's the responsibility of spec writers to provide examples using all possible types of input as a way to reduce this potential over-dependence and misuse of such features, and I can think of several recent specs where that isn't the case. :-)

Andy,

It's the responsibility of spec writers to provide examples using all possible types of input as a way to reduce this potential over-dependence and misuse of such features

You can certainly beg to differ, but I do see annotations with XML override in corner cases where they are really needed as a the right mix of things as to DI. I frankly do not see this as over-use at all. When any cases of "overuse" becomes obvious, you can be rest assured I will be speaking out against it :-). I think you are way off the mark in insisting it is anyone's responsibility to actively advance views they do not agree with. For one, that would just perpetuate the problems that we see. The way I see it, we've done our due diligence in keeping the alternative views (such as 100% XML configuration) viable in the technology. And frankly that takes a lot more hard work than posting a few comments online :-). Cheers, Reza

History actually says that any "new" feature is overused since developers have fascinations with trying 'something different', and so you can add "over-dependence on/misuse of annotations" to that list of yours.

Uncle Bob argues to reduce dependency on Dependency Injection (frameworks): http://blog.objectmentor.com/articles/2010/01/17/dependency-injection-inversion

Uncle Bob argues to reduce dependency on Dependency Injection (frameworks): http://blog.objectmentor.com/articles/2010/01/17/dependency-injection-inversion

This is an excellent analysis and one that is, alas, long overdue, I think... Cheers, Reza

Folks, One of my good friends just pointed out two (hopefully helpful) analysis pieces to the "annotations vs xml" puzzle. Both folks are important players in the shape of CDI/Java EE: Adam Bien's (Java EE author) analysis on annotations vs XML: http://www.adam-bien.com/roller/abien/entry/ejb3_annotations_vs_xml_and. Bob Lee's (Google Guice creator, Dependency Injection for Java co-specification lead) comparison of Guice and Spring: http://code.google.com/p/google-guice/wiki/SpringComparison. Again, nothing against XML for DI proponents, if you disagree with these viewpoints, so be it. Just some additional input to process through the logic circuits :-). Hope it helps, Reza

Thanks for the user friendly introductions, Reza! I find that the information on using CDI in a remote EJB setup to be a little sparse, especially in the case where you don't go through the servlet layer (we call EJB's directly from our client application). Specifically, I want to know, if you have an application that uses rich clients that connects remotely to the application server, can you use CDI to: a) propagate contexts between the client JVM and app server JVM? Most of the examples in the documentation uses the web-profile, where the CDI context is automatically propagated between client and server. Does this apply to remote EJB's too? b) Would a rich client app also support scopes like RequestScoped, ConversationScoped and SessionScoped if you are invoking remote EJB's outside of a servlet container? From my understanding, the scope of an invocation is determined by the servlet engine - it it possible to have this scope determined by the client container instead? Thanks again for the time and effort to explain these concepts!

Francois, Thanks so much for the kind words, I'm trying to do what I can to get the word out there while working on Resin :-). You are right in that there is a great possible integration story between CDI, EJB (or non EJB) remoting and RIA (JavaFX, Ajax, Flex, etc). The closest thing to this at the moment that I know of is here: http://graniteds.blogspot.com/2009/11/new-in-graniteds-210-rc1-early-support.html. There is also a similar concept being developed under Seam 3: http://seamframework.org/Documentation/Seam3Modules. The JBoss guys could tell you more about that than I can... We support remoting for both CDI managed beans and EJB across Hessian in Resin. I'm not sure what the OpenWebBeans are planning in this regard other than of course offering CDI services to EJBs that might have remote/web service end-points. You are right that in this case since the request is not going through the servlet tier, no context is propagated from the client. Hope it helps, Reza

Francois,

We support remoting for both CDI managed beans and EJB across Hessian in Resin.

Whoops...I forgot to mention Hessian has bindings for both JavaFX and Flex. More info here: http://hessian.caucho.com/ria/. Hope it helps, Reza

Thanks Reza, Yes, it helps a lot, thanks for the links. It does seem like cross-VM CDI integration is still a fairly bespoke exercise - perhaps a feature for Java EE 7 :) Regards, Francois

Francois,

It does seem like cross-VM CDI integration is still a fairly bespoke exercise

In many ways, that depends on the success of the initiatives on CDI remoting (including ours). As such, this would probably have been something out of scope at this point, especially given the history of remoting in Java EE :-). At any rate, CDI (the spec) conceptually does not stop anyone from implementing remote propagation - it's really a question of how much demand there is for it (and hence how strongly implementers pursue that angle). Cheers, Reza

This ZK Ajax framework has integrated CDI. Check this thread. https://www.theserverside.com/news/thread.tss?thread_id=59280

I'm not sure I understand all this (almost religious) arguments between DI using XML or annotations. Use whatever you feel is most appropriate for your situation. Personally, I always hated programming in XML, to me it just feels so wrong. I for one am glad we now have annotations to do it properly. And you can still use XML if you want. Also, reading some of the responses above about overuse of DI: it appears to me that some of the problems above were not caused by overuse of DI, but suffered from a deeper issue: poor design (e.g. violating 'tight cohesion, loose coupling', or not knowing the difference between cohesion and coupling). In those cases, overusing DI was just a symptom, not the cause IMO.

Lars, Thanks for the kind words. In case you are interested, the next article should be coming out in a few weeks, covering interceptors, decorators, stereotypes, etc. Cheers, Reza

The default reference implementation initially pointed to Guice.Now that has been replaced with Weld. I would be good to know if anyone has experimented with one over the other and found out interop issues or tend to gravitate from one towards the other.

Time, As far as I know, JBoss has always been responsible for the reference implementation of JSR 299. You might be referring to the name change from WebBeans to CDI? That's covered in the first article in case you did not notice it... You are exactly correct in that a comparison would be great. I personally cannot do it because I am no longer really an independent consultant and never had any Guice customers, limiting my practical experience. Alas, Java has become so politicised these days most people would probably be afraid to engage in such an effort. Hopefully some people will rise above it and go for something like that anyway... Cheers, Reza

All this to solve a problem that has been solved a million years ago. I guess its time something got standardized around this in JEE land but i think its too late, its fractured beyond repair IMHO. There's the Spring Camp, the JEE camp, and the everyone-else camp. We've been using our flavor of IoC for ages (since Java 1.2) which gives all the benefits of solid type-safety that XML cannot and Annotations provide only partially, and a separation of concerns that is unmatched IMHO. Its a design pattern that can be used in any language since it employs interfaces rather than annotations (annotations were built for tool support and are now being abused to replace interfaces IMHO). http://sonymathew.blogspot.com/2009/11/context-ioc-revisited-i-wrote-about.html

There's the Spring Camp, the JEE camp, and the everyone-else camp.

Then of course, there's the vast majority of people that don't belong to any camps and are just trying to get the job done with the right tools and would like to avoid proprietary, home-made solutions if they can help it, especially from people trying to revive dead threads :-). Peace, Reza

Reza, Design patterns are proprietary now? I'm a busy guy so i check threads here & there when i can and remember. This thread needed a bit of reviving haha :)

Good articles, Reza. And appreciate your patient follow-ups. I have used Spring, and I am all for DI (or CDI for that matter). However, I do have reservations about the Annotation approach of CDI. Some of the CDI annotations are wiring directives. That is, they dictate how and what kind of dependencies can be injected. I think that contradicts to the original purpose of DI, and to a certain extend, to the concept of POJO. I believe DI is intended for separation of Interface and Wiring. Programmers code against interfaces only, and the wiring is done later (e.g. during testing and deployment). Although many people hate the XML, the external wiring config makes the separate clean and clear. Putting wiring directives in a bean has following problems: 1. the wiring separation is effectively gone. For example, the @Qualifier basically hard-wires the dependency. Although it's an open-ended wiring, the wiring is still done at coding time. 2. it violates the encapsulation of a POJO. The wiring annotations dictate additional semantics besides the POJO's interface. You can argue that the annotations are part of the interface, but then, they make the interface context dependent - if you re-wire a POJO (by changing the @Qualifier, for example), you effectively change its interface. For the above reasons, the dependencies spill into associated objects anyway, defeating the purpose of DI.

Stereotypes, decorators, interceptors, events, portable, disposers, producers . . . . what is this mess that you are brining into Java, look at Spring it is so simple and elegant do we have to worry about all these things when using Spring?