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 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.

Anoint

FYI, CDI 2 is out, as of 2017-04. See: JSR 365: Contexts and Dependency Injection for JavaTM 2.0. Weld 3 is the Reference Implementation. – Untutored

Answer 1

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.

Pulitzer

I find that the programmatic configuration in Guice is even clearer that beans.xml (where you are back to the "class names are strings in a configuration file, not code" problem). – Steady

Answer 2

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.

Saddler

Regarding the first bullet… CDI 2.0 is now also aimed at usage in Java SE (Standard Edition) as well as Java EE (Enterprise Edition). See JSR 365. The spec is now divided into parts: Part I: Core CDI, Part II - CDI in Java SE, and Part III - CDI in Java EE. – Untutored

Answer 3

Edit 2023-07-13: Now a decade later the world has moved towards small, self contained deployments which mean that your program brings its own web server so you are not dependent on being deployed inside an application server and using what it provides (CDI in this answer). If so, you should not think of CDI (unless it is a hard requirement) but instead strongly consider spring boot which provides the bits and pieces you need, and very good documentation.

——-

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.

Chetchetah

Note that after revisiting this I used @Provides instead. Works much better that @Alternative. – Steady

And as guice was slow on our target platform I turned to dagger which is fantastic! – Steady

Dagger 2 has the great advantage of resolving this at compile time. Strongly recommended. – Steady

Update, regarding compile-time resolution… CDI 4 defines a new CDI Lite profile aimed at support of ahead-of-time compilation. – Untutored

Answer 4

CDI for Guice users is a nice comparison.

Anoint

Answer 5

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}"/>

Arad

CDI works with JavaEE, but it can be used perfectly well in JavaSE environment, as a regular DI framework. – Saddler

@Saddler Yes, but it doessn't yet support 'unmanaged instances', which can make for a difficult transition from Pico/Guice/Spring to CDI for some JavaSE apps. – Ouachita

@Named is not JSR299 but JSR330 ... also it's now supported in Spring. in other hand i've been using Weld in SE context nicely. – Judyjudye

Answer 6

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.

Eran