Google Guice vs. JSR-299 CDI / Weld

Question

Weld, the JSR-299 Contexts and Dependency Injection reference implementation, considers itself as a kind of successor of Spring and Guice.

CDI was influenced by a number of existing Java frameworks, including Seam, Guice and Spring. However, CDI has its own, very distinct, character: more typesafe than Seam, more stateful and less XML-centric than Spring, more web and enterprise-application capable than Guice. But it couldn't have been any of these without inspiration from the frameworks mentioned and lots of collaboration and hard work by the JSR-299 Expert Group (EG).

http://docs.jboss.org/weld/reference/latest/en-US/html/1.html

What makes Weld more capable for enterprise application compared to Guice? Are there any advantages or disadvantages compared to Guice? What do you think about Guice AOP compared to Weld interceptors? What about performance?

My choice

In the end I decided to use Guice because I like the clean programming model which comes without annotations by default. It is much easier to use external libs with Guice than with CDI. AOP is also pretty simple with Guice.

Answer 1

CDI (Weld) hasn't yet been used widely, so a comparison is hard to make. A few points:

• CDI has been designed with integration with EJB3, JSF and other JavaEE standards in mind. CDI has the so called portable extensions which allow third-party libraries to integrate with the lifecycle and internal functioning of a CDI implementation
• CDI has been designed with all possible corner-cases in mind so it is likely that it covers everything you need. Spring, Guice and Seam evolved to such a state, while CDI uses the experience from these three.
• in my opinion, CDI interceptors will not be able to meet all the demands that Spring AOP has met. Perhaps the same goes for Guice AOP. You can't define an interceptor using AspectJ syntax.
• the lack of xml definitions is both an advantage and a disadvantage and some people (rightly in some cases) prefer xml configuration.
• the extended use of qualifier annotations will (in my opinion) generate some big messes if not used carefully.

Answer 2

Before trying to answer your question, let me just add an important piece of information: JSR 330 (@Inject) was standardized by Guice and Spring projects (announcement from May 2009) and is being reused in JSR 299. This covers basic DI mechanisms in terms of declaring an injection point.

Now, back to the question - with the disclaimer that I have far more experience with Spring than with Guice.

Enterprise capabilities in Weld

• Alternative configuration mechanisms have a very clean design in JSR-299 and allow for configuration mechanisms outside of the Java code (beans.xml).
• Events are a very powerful thing and fit nicely with JMS. I just found an Event Bus for Guice, but I cannot say how that compares.
• Portable extensions are an SPI that can be used to integrate with existing technology or wrap legacy code in a clean way.

Advantages / Disadvantages

Note: I will try to add a few items here later, but this answer is already longer than I had expected, sorry.

• Weld/CDI

  • Standardization: If something is standardized and there is a good implementation, a lot of people will be using it. Example: Built-in scopes in Weld provide a few more scopes than Guice or Spring. All of these can be extended, but application frameworks will rather rely on standard scopes if they are being used by a large community.
  • Container support: this is similar to the previous item, but a major argument for adoption. Major open source application servers, such as Glassfish and JBoss 6 provide CDI support (see here).

• Guice/Spring

  • Actual application: Most of the existing applications will be using Guice/Spring already. Spring/Guice have always built on standards and provided new capabilities where no standards existed or could not be used. If you follow with the respective best-practices, the framework will help you make your application standards-based and clean.

AOP and Interceptors

This is a very heavily discussed topic, and I cannot favor one over the other. Both mechanisms are very powerful but require at least a minimum understanding of the application's architecture. Also have look at Decorators and the previously referenced Events. It is best to go with the right tool, but don't forget that if a developer has to work with one of these mechanisms it is a good thing if he/she understands the concept.

Performance

Unfortunately I could not look into this yet, but there are a few rules I try to follow, especially when using a framework that gives you a lot of functionality without you noticing it:

• Whenever possible, prefer a single wiring step over multiple lookups at runtime.
• If possible, do all the wiring on application initialization.
• Any interception step or AOP proxy adds a few method calls to the stack.