6 ms·

What about dependency injection in modern java - is Guice or spring still the de facto standard?

exabrial 12y ago
I agree... can't live without Dependency Injection (one of the reasons I refuse to move off of Java). I've been using CDI and TomEE for small simple stuff (it just works). Can't stand Spring Framework anymore. It set out to replace the bloatware of Java EE 1.5 but it ended up becoming what it was meant to replace.
- jmgtan 12y ago
  You should give the latest version a try. Spring implemented JavaConfig, which allows you to avoid XML altogether. Coupled with the ComponentScan annotation, it can't get any simpler.
- bsaul 12y ago
  Genuinely curious : i've been playing with dependency injection, and really never got to understand the true use of it. I mean, what's the point of being able to replace an implementation outside the source code itself ? You'd still have to extensively test the thing and recompile it... Is there more to it than just being able to replace a class by its mock up, for unit testing ?
  - volune 12y ago
    IMO dependency injection encourages making very deep object graphs. constructor argument passing can be cumbersome, but jumping into new code it is much more clear, and it encourages you to write flatter code structures. i go without.
  - snikeris 12y ago
    I think the point is that you don't want to be instantiating (and thus configuring) a dependency at the site where it is used. The code in class Foo should be limited to implementing Foo, not instantiating and configuring its dependency Bar.
    - wtetzner 12y ago
      So why not just pass its dependency as a constructor argument?
      - snikeris 12y ago
        Passing a dependency as a constructor argument is dependency injection: http://en.wikipedia.org/wiki/Dependency_injection#Constructor_injection http://en.wikipedia.org/wiki/Dependency_injection#Constructo...
        wtetzner 12y ago
        Right, my point was more "why do you need a framework to call constructors for you?".
      - UK-AL 12y ago
        That's what IoC containers do, or via setter. However a IoC container can automatically create, and send through the object based convention(IMessageQueue -> MappedTo -> MessageQueue) or configuration (IMessageQueue -> MappedTo -> APMQMessageQueue).
  - oh_sigh 12y ago
    Not to sound snarky, but you should read any introduction to dependency injection. The benefits are generally covered very thoroughly, and what you said is not usually considered a benefit.
    - kyberias 12y ago
      Wikipedia article on dependency injection, section titled "Advantages", _first_ bullet: "The result is more independent clients that are easier to unit test in isolation using stubs or mock objects that simulate other objects not under test." Would you like to try again?
      - oh_sigh 12y ago
        The OP said "I mean, what's the point of being able to replace an implementation outside the source code itself." Where, in what you posted, does it reference being able to replace implementations outside of the source code itself? Would you like to try again?
  - deleted 12y ago
    [deleted]
  - rymndhng 12y ago
    It depends. One thing that I thought is an interesting feature of Spring, is that it allows the framework to inject code between your dependencies like decorators. This allows them to do aspect-oriented-programming transparently. And I think there's some interesting ideas here. For example, you can mark the interface of a class as @Transactional, and all your implementations will get the behavior.
    - UK-AL 12y ago
      I think that's the interception way of AOP? Unity IoC in c# also does this. The IoC container will return transparent proxy(Not the original object), which then calls the underlying method(after doing the AOP behaviour).
      - Glide 12y ago
        Be careful of using these though. I had an obscure bug using dynamic proxy (castle dynamic proxy2) a while ago in a WPF application. I was proxying to an interface so it created a proxy object in between that in the actual class so it was eating my C# event. Changing the proxying from an interface to a subclass fixed it. Boy that was a fun one to figure out.
  - twistedpair 12y ago
    When you've got a complex graph of objects and dependencies between them, DI can easily take care of instantiating an A and feeding it to a B that requires an A and so on and so on. In our projects we'll have a DebuggerFooImpl, a MockFooImpl, and a ProdFooImpl. Spring's AppConfig classes then can create the proper object at startup based on environment profiles and no consumers have to do any more than ask for the Foo object to be injected into them, isolating them from any environment awareness/coupling. There are other benefits from DI as well, but the above at the low hanging fruit, isolating the complexity of object creation from the object's consuming classes.
  - Terr_ 12y ago
    It tries to disentangle two different problems: 1. Does my class work appropriately? Does it encapsulate/hide/abstract the right behavior? Does it function correctly with other classes that implement certain inferfaces? 2. Is my network of classes correctly defined so that I can use them all together in a particular way? http://programmers.stackexchange.com/questions/92393/what-does-the-spring-framework-do-should-i-use-it-why-or-why-not/92672#92672 http://programmers.stackexchange.com/questions/92393/what-do...
  - ddeck 12y ago
    There are definitely more advantages than just the unit testing side. The Google IO talk on Guice does a pretty good job of explaining the benefits: https://www.youtube.com/watch?v=hBVJbzAagfs https://www.youtube.com/watch?v=hBVJbzAagfs
- AnimalMuppet 12y ago
  It occurs to me that dependency injection has this strange similarity to functional programming. I mean, clearly, you're playing with objects instead of functions, and they can have state, and so on, so it's not functional. But still, there's a similarity in how you're breaking things apart. Spring: Maybe the problem is that Jave EE 1.5 was a reasonably good solution for the problems it was trying to solve? Maybe you can't do radically better and still actually solve the problems?
- UK-AL 12y ago
  What web framework can use that works with CDI, and standard EE stuff that is request-repoonse based?
veeti 12y ago
I only do Java on Android, but Dagger (https://square.github.io/dagger/ https://square.github.io/dagger/) might be a nice lightweight alternative.
- ddeck 12y ago
  Dagger is definitely more appropriate for Android applications and was developed specifically to address the issues with using something like Guice on mobile. That said, I love Guice and use it exclusively as it has a superset of features and startup performance is irrelevant in my area. As Christian Gruber from the development team put it: Dagger is a joint effort by Square, Google, some individual contributors from other places such as Nextflix, and is descended conceptually from Guice - specifically from MiniGuice. It addresses some key challenges our users faced with Guice. From Square’s side (/u/swankjesse can clarify this) it was the need to get high-performance, low-startup dependency injection on Android. From our side, it was that and the desire to trim the API weight of dependency injection, to reduce the user confusion that comes from reflection and bytecode generation in stack traces and debugging environments, and to get early validation of your graph’s wiring. Dagger is a substantial direction shift for Google, and we are investing time and resources in it. Guice will always have a superset of features compared to Dagger, though we do have projects using Dagger on the server and in stand-alone java apps. But Dagger is not as evolved in terms of the surrounding "scaffolding" code (servlet support, etc.) as Guice, and won’t be for quite some time. Additionally, some teams will need or want some advanced Guice features that will never make it in to Dagger. [1] [1] http://www.reddit.com/r/java/comments/1y9e6t/ama_were_the_google_team_behind_guava_dagger http://www.reddit.com/r/java/comments/1y9e6t/ama_were_the_go...
pron 12y ago
I'll address that in part 3. Basically jsr330 is a good standard, and it's implemented by Guice, Dagger and Spring
- peterarmstrong 12y ago
  If you're planning at least 3 parts, have you considered turning this tutorial into a Leanpub book? It's the perfect start to one... (Disclosure: I'm a Leanpub cofounder)
  - pron 12y ago
    I don't know. I'll give it a try.
    - peterarmstrong 12y ago
      Cool. Let me know how it goes!
jebblue 12y ago
I try to avoid it as much as possible. It's confusing at least to me and makes maintaining code over a long haul an arduous dull process. I'm getting to the point where I prefer straight JDBC over Hibernate too. It takes longer to code but I've seen speed increases of several times over Hibernate in those situations. JDBC code is just linear but I feel it's easier to maintain in the long run.
- edwinnathaniel 12y ago
  Speed is not the only concern when it comes to JDBC vs ORM (JPA/Hibernate). The more complex the data model, the more one needs to know the inner working of JPA. I've shared my struggle understanding how JPA works even for a medium-level complexity of the JPA entities. Some of the problems I've encountered using JPA: - The whole EntityManager act as L1 cache occasionally tripped me when writing Integration-Tests - The relationship direction (owning, etc) can be confusing to learn - Reference vs Lazy vs Eager load Having said that, HBM2DDL is a nice tool that can work as maven plugin such that changes on the JPA entities can resulted the DDL to be updated properly thus maintaining consistency between Java Data Model and the DB schema.
- JustSomeNobody 12y ago
  Thankfully I am seeing more and more comments like this. I really think we off the deep end with all this. Simple is key.
- EdwardDiego 12y ago
  I agree. Hibernate has become a downright liability at times in our codebase. These days I only use it in new code for query parameterization and result row transforms into models. Speaking of which, if anyone knows of a good library for query parameterization alone, let me know...
  - ZitchDog 12y ago
    JDBI is quite good: http://jdbi.org/ http://jdbi.org/
craigching 12y ago
My preference for DI is Declarative Services in OSGi. OSGi is a nice specification for creating modular Java systems.
osi 12y ago
i've seen a resurgence of 'new'

I agree... can't live without Dependency Injection (one of the reasons I refuse to move off of Java). I've been using CDI and TomEE for small simple stuff (it just works). Can't stand Spring Framework anymore. It set out to replace the bloatware of Java EE 1.5 but it ended up becoming what it was meant to replace.

jmgtan 12y ago
You should give the latest version a try. Spring implemented JavaConfig, which allows you to avoid XML altogether. Coupled with the ComponentScan annotation, it can't get any simpler.
bsaul 12y ago
Genuinely curious : i've been playing with dependency injection, and really never got to understand the true use of it. I mean, what's the point of being able to replace an implementation outside the source code itself ? You'd still have to extensively test the thing and recompile it... Is there more to it than just being able to replace a class by its mock up, for unit testing ?
- volune 12y ago
  IMO dependency injection encourages making very deep object graphs. constructor argument passing can be cumbersome, but jumping into new code it is much more clear, and it encourages you to write flatter code structures. i go without.
- snikeris 12y ago
  I think the point is that you don't want to be instantiating (and thus configuring) a dependency at the site where it is used. The code in class Foo should be limited to implementing Foo, not instantiating and configuring its dependency Bar.
  - wtetzner 12y ago
    So why not just pass its dependency as a constructor argument?
    - snikeris 12y ago
      Passing a dependency as a constructor argument is dependency injection: http://en.wikipedia.org/wiki/Dependency_injection#Constructor_injection http://en.wikipedia.org/wiki/Dependency_injection#Constructo...
      - wtetzner 12y ago
        Right, my point was more "why do you need a framework to call constructors for you?".
    - UK-AL 12y ago
      That's what IoC containers do, or via setter. However a IoC container can automatically create, and send through the object based convention(IMessageQueue -> MappedTo -> MessageQueue) or configuration (IMessageQueue -> MappedTo -> APMQMessageQueue).
- oh_sigh 12y ago
  Not to sound snarky, but you should read any introduction to dependency injection. The benefits are generally covered very thoroughly, and what you said is not usually considered a benefit.
  - kyberias 12y ago
    Wikipedia article on dependency injection, section titled "Advantages", _first_ bullet: "The result is more independent clients that are easier to unit test in isolation using stubs or mock objects that simulate other objects not under test." Would you like to try again?
    - oh_sigh 12y ago
      The OP said "I mean, what's the point of being able to replace an implementation outside the source code itself." Where, in what you posted, does it reference being able to replace implementations outside of the source code itself? Would you like to try again?
- deleted 12y ago
  [deleted]
- rymndhng 12y ago
  It depends. One thing that I thought is an interesting feature of Spring, is that it allows the framework to inject code between your dependencies like decorators. This allows them to do aspect-oriented-programming transparently. And I think there's some interesting ideas here. For example, you can mark the interface of a class as @Transactional, and all your implementations will get the behavior.
  - UK-AL 12y ago
    I think that's the interception way of AOP? Unity IoC in c# also does this. The IoC container will return transparent proxy(Not the original object), which then calls the underlying method(after doing the AOP behaviour).
    - Glide 12y ago
      Be careful of using these though. I had an obscure bug using dynamic proxy (castle dynamic proxy2) a while ago in a WPF application. I was proxying to an interface so it created a proxy object in between that in the actual class so it was eating my C# event. Changing the proxying from an interface to a subclass fixed it. Boy that was a fun one to figure out.
- twistedpair 12y ago
  When you've got a complex graph of objects and dependencies between them, DI can easily take care of instantiating an A and feeding it to a B that requires an A and so on and so on. In our projects we'll have a DebuggerFooImpl, a MockFooImpl, and a ProdFooImpl. Spring's AppConfig classes then can create the proper object at startup based on environment profiles and no consumers have to do any more than ask for the Foo object to be injected into them, isolating them from any environment awareness/coupling. There are other benefits from DI as well, but the above at the low hanging fruit, isolating the complexity of object creation from the object's consuming classes.
- Terr_ 12y ago
  It tries to disentangle two different problems: 1. Does my class work appropriately? Does it encapsulate/hide/abstract the right behavior? Does it function correctly with other classes that implement certain inferfaces? 2. Is my network of classes correctly defined so that I can use them all together in a particular way? http://programmers.stackexchange.com/questions/92393/what-does-the-spring-framework-do-should-i-use-it-why-or-why-not/92672#92672 http://programmers.stackexchange.com/questions/92393/what-do...
- ddeck 12y ago
  There are definitely more advantages than just the unit testing side. The Google IO talk on Guice does a pretty good job of explaining the benefits: https://www.youtube.com/watch?v=hBVJbzAagfs https://www.youtube.com/watch?v=hBVJbzAagfs
AnimalMuppet 12y ago
It occurs to me that dependency injection has this strange similarity to functional programming. I mean, clearly, you're playing with objects instead of functions, and they can have state, and so on, so it's not functional. But still, there's a similarity in how you're breaking things apart. Spring: Maybe the problem is that Jave EE 1.5 was a reasonably good solution for the problems it was trying to solve? Maybe you can't do radically better and still actually solve the problems?
UK-AL 12y ago
What web framework can use that works with CDI, and standard EE stuff that is request-repoonse based?

veeti 12y ago

I only do Java on Android, but Dagger (https://square.github.io/dagger/ https://square.github.io/dagger/) might be a nice lightweight alternative.

ddeck 12y ago
Dagger is definitely more appropriate for Android applications and was developed specifically to address the issues with using something like Guice on mobile. That said, I love Guice and use it exclusively as it has a superset of features and startup performance is irrelevant in my area. As Christian Gruber from the development team put it: Dagger is a joint effort by Square, Google, some individual contributors from other places such as Nextflix, and is descended conceptually from Guice - specifically from MiniGuice. It addresses some key challenges our users faced with Guice. From Square’s side (/u/swankjesse can clarify this) it was the need to get high-performance, low-startup dependency injection on Android. From our side, it was that and the desire to trim the API weight of dependency injection, to reduce the user confusion that comes from reflection and bytecode generation in stack traces and debugging environments, and to get early validation of your graph’s wiring. Dagger is a substantial direction shift for Google, and we are investing time and resources in it. Guice will always have a superset of features compared to Dagger, though we do have projects using Dagger on the server and in stand-alone java apps. But Dagger is not as evolved in terms of the surrounding "scaffolding" code (servlet support, etc.) as Guice, and won’t be for quite some time. Additionally, some teams will need or want some advanced Guice features that will never make it in to Dagger. [1] [1] http://www.reddit.com/r/java/comments/1y9e6t/ama_were_the_google_team_behind_guava_dagger http://www.reddit.com/r/java/comments/1y9e6t/ama_were_the_go...

pron 12y ago

I'll address that in part 3. Basically jsr330 is a good standard, and it's implemented by Guice, Dagger and Spring

peterarmstrong 12y ago
If you're planning at least 3 parts, have you considered turning this tutorial into a Leanpub book? It's the perfect start to one... (Disclosure: I'm a Leanpub cofounder)
- pron 12y ago
  I don't know. I'll give it a try.
  - peterarmstrong 12y ago
    Cool. Let me know how it goes!

jebblue 12y ago

I try to avoid it as much as possible. It's confusing at least to me and makes maintaining code over a long haul an arduous dull process. I'm getting to the point where I prefer straight JDBC over Hibernate too. It takes longer to code but I've seen speed increases of several times over Hibernate in those situations. JDBC code is just linear but I feel it's easier to maintain in the long run.

edwinnathaniel 12y ago
Speed is not the only concern when it comes to JDBC vs ORM (JPA/Hibernate). The more complex the data model, the more one needs to know the inner working of JPA. I've shared my struggle understanding how JPA works even for a medium-level complexity of the JPA entities. Some of the problems I've encountered using JPA: - The whole EntityManager act as L1 cache occasionally tripped me when writing Integration-Tests - The relationship direction (owning, etc) can be confusing to learn - Reference vs Lazy vs Eager load Having said that, HBM2DDL is a nice tool that can work as maven plugin such that changes on the JPA entities can resulted the DDL to be updated properly thus maintaining consistency between Java Data Model and the DB schema.
JustSomeNobody 12y ago
Thankfully I am seeing more and more comments like this. I really think we off the deep end with all this. Simple is key.
EdwardDiego 12y ago
I agree. Hibernate has become a downright liability at times in our codebase. These days I only use it in new code for query parameterization and result row transforms into models. Speaking of which, if anyone knows of a good library for query parameterization alone, let me know...
- ZitchDog 12y ago
  JDBI is quite good: http://jdbi.org/ http://jdbi.org/

craigching 12y ago

My preference for DI is Declarative Services in OSGi. OSGi is a nice specification for creating modular Java systems.

osi 12y ago

i've seen a resurgence of 'new'