Google Guice vs. JSR-299 CDI / Weld

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 almost without annotations besides @Inject by default. It is much easier to use external libs with Guice than with CDI. AOP is also pretty simple with Guice.

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.

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.

CDI for Guice users is a nice comparison.

The most important feature CDI has opposed to Guice, is that it is a standard part of Java EE 6.

The importance of this cannot be underestimated, as it means that CDI is the DI-standard you should use when coding web applications.

A while back I had a look at the technologies to be able to determine how we could have a standard core distribution - suitably prepared - where we could add extra modules at will which could override existing functionality without having to change the core modules. I.e. add an extra jar, and the functionality activates automatically.

It turned out that the best way for us to do this for a code base used in both desktop and web applications, was to use JSR-330 annotations for our code, and then use either CDI or Guice (SVN, coming real soon now in 3.0) as the engine.

After a few projects I've found that I like the Guice configuration best instead of the opaque magic happening in Weld. Additionally I found that the way to do what we want as described above with Weld, I have to mark the class in the extra jar as @Alternative, and then mention in beans.xml that I want the alternative class enforced (and that is not robust against refactoring).

But, all in all, JSR-330 allows us to do something which was very tedious and fragile before (because new binds so extremely tightly), and that is a great win. I can strongly recommend looking into DI if you have any need like this.

Another differentiator is that CDI is very Java EE oriented. It provides a mechanism to glue the different Java EE subsystems together.

Ie. By annotating a bean with @Named("book"), the bean becomes known in the unified EL (Expression Language) as 'book'.

Then you can use it in a JSF page for instance:

	<h:outputLabel value="Book title:" for="bookTitle"/>
	<h:outputText id="bookTile" value="#{book.title}"/>

I have used Guice in an AWS Lambda serverless application. AWS recommends using Guice or Dagger over Spring in a Lambda function. See AWS Lambda best practices

The primary reason is that Guice and Dagger are smaller frameworks and have faster start up time, which is essential in Lambda.

Although the OP hasn't mentioned Spring, both Spring and CDI/weld are meant for enterprise level applications, which often require additional features that these frameworks provide. Hence for smaller applications, which only require DI, Guice or Dagger would be optimal.