views:

81

answers:

3

I am planning to use dependency injection framework.
what should I choose? Guice or Spring?
I will use java configuration both ways. also my application is pure java j2se, not web/j2ee application and I don't plan to use spring's rich capabilities. my main concern about guice is that it is much less popular and not in common use. I want a mature, documented and easy to use DI framework.
Can you tell me what is the preferred option from your experience?

+2  A: 

+1 for Spring

  • Nice documentation
  • Support for more than just dependency injection (which you might eventually want to use)
  • Customizable wrappers for routines tasks
  • Export POJOs as MBeans, AOP with no code changes etc.. - some of the benefits you have the Spring head start.
madhurtanwani
+2  A: 

Guice provides injection only - it disappears once the object graph has been created. Any additional "features" that may be required are generally available via extensions or very easy to add, but you should always ask why. Just because it is there to use is not a reason to consider something.

The benefit of Guice is that it is simple to use and that it is type safe. Type safety is paramount from my perspective as Spring has resulted in many headaches for myself.

The choice in the end is undoubtedly yours, but I'd suggest you research both before you make a decision.

gpampara
isnt spring 3.0 is also type safe?
ohadshai
@ohadshai: I've got no idea. After the complications with Spring 2.x we migrated to Guice and have never looked back. Spring 3.0 might be better with type safety, but it's no longer an option for us.
gpampara
+1  A: 

Spring has a little bit of everything, which isn't necessarily a bad thing, but if you have to modify the default behavior of some of their classes it can be a pain to make things happen. That said, if you're willing to spend a couple hours looking at the source, you can make it happen. Spring is much more than just dependency injection.

Guice does AOP as well as DI. I haven't used Guice, but I've been reading up on it, looking to use it in one of my projects.

Spring trends towards setting everything as a getter/setter. In order to do some initialization after setting the properties of a spring class, you will need to either specify an init method on the bean itself or implement the initializing bean interface. Per my understanding of Guice, it prefers constructor arguments instead of setting getters and setters, so that isn't really needed.

Spring can do constructor based creation if you wanted to go that route, however it is much less clear what is going on. When doing it via properties you have the property name as a reference.

Guice does not use xml files for configuration. As with spring, I currently have a couple hundred lines of various configs in various xml files. I don't make heavy use of annotation for much of the code or autowiring, so my xml files are longer than they need to be.

I'm not sure if Guice supports this or easily supports it, but with spring you can do session backed beans which does away with a lot of explicitly checking the session in a web application.

There is also a way to register Spring beans inside of Guice, so they can somewhat work together. I'm not sure where this would be applicable/necessary.

If you want more light weight/easier to get start I would guess Guice is quicker way to get started. Spring took a little getting used to, particular some of the caveats with their transactional AOP when first starting out. So to echo the first answer, it depends on how you plan on using it.

Edit: Also, if you want something that will apply to both .Net and Java, there is a .Net version of Spring. When I used the .Net version, there weren't analogues for some of the WebMVC code, but for the most part, the concepts were the same. Since my company does both Java and .Net work, with the same developers, Spring + Hibernate works great for us.

Scott