Discussions

News: On Promoting Dependency Injection with Google Guice

  1. http://www.theserverside.com/tutorial/On-Promoting-Dependency-Injection-with-Guice

    In our ongoing attempt to get people programming with Google Guice, we're throwing another great article into the mix, only this time, it's written by someone who actually knows what they're talking about. And to think, someone actually suggested that we weren't giving enough ink to the @Inject annotation...

    On Promoting Dependency Injection with Guice



    Here are the other, introductory tutorials on Google Guice that have been running throughout the week:

    Tutorial 1: Getting Started with Google Guice: Environment Setup and Configuration

    Tutorial 2: The Simplest IoC Example You've Ever Seen, with Google Guice

    These tutorials can also be viewed as CBT Videos:

    Tutorial 1 as a Video CBT 

    Tutorail 2 as a Video CBT

    Threaded Messages (15)

  2. Container injection[ Go to top ]

    The problem with dependency injection by guice and also by Spring is that it isn't really dependency injection anymore, but container injection. Each objects knows about its container and knows about existing beans and the environment it runs in. A very bad development imho.

     

  3. Container injection[ Go to top ]

    The problem with dependency injection by guice and also by Spring is that it isn't really dependency injection anymore, but container injection. Each objects knows about its container and knows about existing beans and the environment it runs in. A very bad development imho.

     

    Really?

    So, Spring, Guice, CDI, EJB3, Jboss MicroContainer and others are bad IoCs?

    IMHO all these IoC are very similar each others.

    ...and are all good tools.

    One thing is the IoC, another thing  is a plugin component container, like NetBeans Platform or Eclipse Platform, that are "dynamic" IoC.

    But a really dynamic IoC is not needed in server programming, at least until nowadays.

     

     

  4. Container injection[ Go to top ]

    Spring was a good IOC container in the beginning but today it is kinda sucky imho (I was a big Spring enthousiast). But the most Spring code I see today is litered with all kinds of IOC annotations in the code that assume somehting of the environment. So all kinds of autowiring crap, qualifiers and other junk that should not be part of the code.

    Java code should be 100% free of DI related annotations, so the same components can easily be reused in different configuration. I seen teammembers and myself spending way too much time why something doesn't work like expected.

    I think the problem with Spring (and a lot of other frameworks) is that if you give consultants too much time, that a framework keeps growing.. and growing.. until it becomes the problem it tried to solve in the beginning. Reduce unwanted complexity (and Spring did a great job with that in the beginning).

  5. Container injection[ Go to top ]

    Spring was a good IOC container in the beginning but today it is kinda sucky imho (I was a big Spring enthousiast). But the most Spring code I see today is litered with all kinds of IOC annotations in the code that assume somehting of the environment. So all kinds of autowiring crap, qualifiers and other junk that should not be part of the code.

    Java code should be 100% free of DI related annotations, so the same components can easily be reused in different configuration. I seen teammembers and myself spending way too much time why something doesn't work like expected.

    I think the problem with Spring (and a lot of other frameworks) is that if you give consultants too much time, that a framework keeps growing.. and growing.. until it becomes the problem it tried to solve in the beginning. Reduce unwanted complexity (and Spring did a great job with that in the beginning).

    In the dark ages, when J2EE was a huge monster, peoplr chanted this all the time: Just because J2EE has all these stuff like EJB 2.x, etc. etc.. does not mean you have to use it. Only use what you need.

    The same goes for Spring. Today's Spring is no less complex than yester-year's J2EE. That does not mean that I have to use all of its features.  I like Spring for the things it adds value to my development - namely XML based configuration. I just dont use other noise like Autowiring, Components, scans etc. For the kind of HUGE projects I build, these annotations are confusing and we do not use it.

    I am reminded of a article that came out in 2006 in onjava.com. Guess what was the first best practice? "Do not use Autowiring in real big projects". http://onjava.com/pub/a/onjava/2006/01/25/spring-xml-configuration-best-practices.html

    Having said that, there are places where Autowiring is preferred. It is the testing part. Spring projects that used EJBs might recall that they had to maintain two spring config xmls - One to be bundled with the Java EE jar/WAR/EAR. Another one for out of container testing. Autowiring and Component annotations are great fit for that. So, we need to use common sense and use the tools wisely. A fool with a tool is essentially still a fool.

    But we also dont make all decisions and have to frequently work on projects that have got one trick Gurus. When we walk into such projects, we find that these folks are buzzword driven and have already used these annotations all over the place and there is no one such place where we can look and understand what's going on.. For such places, I recommend writing some simple scripts (Groovy anybody ?) that actually parse the Java files looking for all sorts of annotations and also looking at existing spring config xmls (if any), traverse connected Eclipse projects in classpath  and repeat this recursively to build a group of connected spring xmls. Then you can open in a bean graph viewer (used to part of Spring IDE plugins for Eclipse). All this sounds scary, but it is simple. You put the effort into it once and then is serves you lifelong in all these tricky situations.

    I have not looked at the Spring IDE for a while or their current incarnation. Perhaps they might have already have this feature.

    I am a visual guy, and I believe many are. We need to get the entire picture to drill down and understand the projects that get thrown at us. Developing a script like this is a good way to address the complexity

    Peace,

    Srikanth Shenoy

    ObjectSource

  6. "I am reminded of a article that came out in 2006 in onjava.com. Guess what was the first best practice? "Do not use Autowiring in real big projects". http://onjava.com/pub/a/onjava/2006/01/25/spring-xml-configuration-best-practices.html

    "

     I just re-read this article ... haha

  7. You've unmeantly told the exact thing we all observing for awhile now. SpringSource guys try to be everyting for everyone and they do almost everyting to duplicate mistakes of J2EE platform. It's just getting to big and container dependant. Spring tools aren't easy anymore.

  8. Container injection[ Go to top ]

    The problem with dependency injection by guice and also by Spring is that it isn't really dependency injection anymore, but container injection. Each objects knows about its container and knows about existing beans and the environment it runs in. A very bad development imho.

    Can't speak for Guice but how does Spring make every object know about its container, existing beans or the environment unless the developer has told the object in configuration. Spring only injects/proxies or contains what you tell it to.

    I can have two objects that are in a Spring container but they don't need to know anything about the container or each other.

  9. Container injection[ Go to top ]

    Whether your classes know about the Container or not  , I think is not so important.

    I mean. your managed beans (by Spring, Guice, CDI, EJB3...) does not continue to live and work outside your container.

    In other worlds: whether you put Spring's import annotations or not, is not so important: outside spring your code simply does not work!

    IMHO it is better to have a Container that does not force you to import its code, but, really, it does not matter so much.

    Finally I prefer xml configuration over @annotation configuration for this reason.

  10. Container injection[ Go to top ]

    Exactly. If they all would standardise, on JSR-299 for example, they would reach the goal of dependency injection.

    The problem with dependency injection by guice and also by Spring is that it isn't really dependency injection anymore, but container injection. Each objects knows about its container and knows about existing beans and the environment it runs in. A very bad development imho.

     

  11. Spring is not "Container Injection"[ Go to top ]

     

    Your statement is simply not true, when an object is created by the container dependencies are injected, it is as simple as that.

    The container may know about all the objects its created but that is irrelevant to the functioning code.

    IOC specifically replaced the old state of things where every object knows where to get its dependencies, or worse statics were used everywhere.

    It might be a good idea to read up on IOC and DI to better understand what it is and what it isn't.

    Cheers.

     

    The problem with dependency injection by guice and also by Spring is that it isn't really dependency injection anymore, but container injection. Each objects knows about its container and knows about existing beans and the environment it runs in. A very bad development imho.

     

  12. Spring is not "Container Injection"[ Go to top ]

    That depends on how you use it. I love di, don't get me wrong (which you appearently have) and you can use Spring (and the other DI frameworks) in the old school way.. so in Java you just define your logic and inject the dependencies either through a consuctor (my favorite)or through a setter.

     

    But a lot of modern code is litered with autowiring, component scans, qualifiers and other crap like that which assumes a certain type of di container running (not that bad since you won't change that often), but what is worse is that the object is starting to gain information about its environment (especially with qualifiers).

     

    Another problem is that it is much harder to figure out which object is injected where (especially with component scans). Where from time to time you get a big surprise.

  13. Peter,

    I understand where you're coming from but to me it seems your basic beef is about XML vs annotations. With XML your code stays completely 'clean' as all the meta data, including configuration, dependency graphs, relations, etc are completely externalized.

    On the other hand, XML is almost always verbose, not type-safe and makes the meaning of the code hard to read. XML code is mainly verbose because of the simple reason that very few people have the talent to create a clean XML schema. Most people introduce extra tags where non are needed, forget that attributes exist, build tags based on a 'hyphen hierarchy' instead of utilizing parent-child relationships, force people to specify everything instead of assuming some sensible defaults, etc. I love Java EE, but I have to admit that it is the worst offender here. Look at all the Java EE XML files (web.xml, application.xml, faces-config.xml, etc) NONE use attributes!

    Sun had a splendid explanation in their J2EE tutorial years ago that explained how to create XML dialects correctly, when to use attributes and when not to use them, etc. However, their own engineers have some sort of holistic and totally incomprehensible hatred against the concept 'attribute' in XML and completely abandoned it.

    In part, annotations are simpler (in Java EE), just for the fact that attributes and sensible defaults are used.

    That aside, annotations do have the advantage of needing to specify less, since they automatically have a context to work with. You don't have to specify a target class name for an annotation, if that can simply be deduced from the class in which the annotation appears.

    All of this is true for a lot of different cases, not just DI. The same thing is true for JPA entities and JSF managed beans. Most people seem to prefer specifying the ORM mapping information in their entity, at the cost of coupling the entity to JPA. Of course, one could still map the same entity to another ORM system, as the JPA annotations can simply be ignored. You'd have to satisfy the compile time dependency, but other than that annotations aren't active things by themselves. I would like very awkward though if this other ORM system would also be based on annotations. Having two sets of annotations on a single class, one for ORM 1 and the other for ORM 2 would be utterly confusing I guess.

    In a way, DI annotations feel a little like a 'managed new'. Your code is not totally oblivious to what dependencies it gets and from who (as with XML), but it's also not completely coupled as when instantiating dependencies directly with the new operator.

     

     

  14. Container injection[ Go to top ]

    I found a feature in Java that, I think, solves the "container injection" problem.  It's called an interface and it has been in Java since it was alpha.  I just tried it and it allowed me to decouple my container implementation from my code.

     

    I prefer XML configuration so I have no framework dependencies in my pojos.  

  15. Container injection[ Go to top ]

    Completely agree 100%. I like to stick with XML (external configuration) for dependency injection, AND annotations (hardcode configuration) for other stuff where I profit from the known context, the proximity to the code that depends on it, etc.

  16. Guice doesn't cut it[ Go to top ]

    Spring has a boat load of facilities indispensable to any serious application beyond dependency injection:

    1. Resource loading

    2. BeanFactoryAware

    3. ApplicationListener for refresh events etc.

    4. Bean Pre/Post Processors

    5. AOP

    etc. etc.We have a ton of "magic" in our systems thanks to the above facilities.

    In Guice, these features are conspicuous by their absence of these and the last I checked Guice didn't support javax.inject.Inject.