Google Guice与PicoContainer的依赖注入

Question

My team is researching dependency injection frameworks and is trying to decide between using Google-Guice and PicoContainer.

We are looking for several things in our framework:

1. A small code footprint - What I mean by a small code footprint is we don't want to have dependency injection code litter everywhere in our code base. If we need to refactor down the road, we want it to be as easy as possible.
2. Performance - How much overhead does each framework have when creating and injecting objects?
3. Ease of use - Is there a large learning curve? Do we have to write mounds of code to get something simple working? We want to have as little configuration as possible.
4. Community size - Larger communities usually means that a project will continue to be maintained. We don't want to use a framework and have to fix our own bugs ;) Also any questions we have along the way can (hopefully) be answered by the framework's developer/user community .

Comparisons of the two frameworks against the listed criteria would be greatly appreciated. Any personal experiences that help to compare the two would also be extremely helpful.

Disclaimer: I'm fairly new to dependency injection so excuse my noob-ness if I asked a question that isn't pertinent to this discussion.

Answer 1

You may want to include Spring in your list of Dependency Injection frameworks you are considering. Here are some answers to your questions:

Coupling to the framework

Pico - Pico tends to discourage setter injection but other than that, your classes don't need to know about Pico. It's only the wiring that needs to know (true for all DI frameworks).

Guice - Guice now supports the standard JSR 330 annotations, so you do not need Guice specific annotations in your code anymore. Spring also supports these standard annotations. The argument that the Guice guys use is that without a Guice annotation processor running, these shouldn't have an impact if you decide to use a different framework.

Spring - Spring aims to allow you to avoid any mention of the Spring framework in your code. Because they do have a lot of other helpers / utilities etc. the temptation is pretty strong to depend on Spring code, though.

Performance

Pico - I'm not too familiar with the speed characteristics of Pico

Guice - Guice was designed to be fast and the comparison mentioned in the reference has some numbers. Certainly if speed is a primary consideration either using Guice or wiring by hand should be considered

Spring - Spring can be slow. There has been work to make it faster and using the JavaConfig library should speed things up.

Ease of use

Pico - Simple to configure. Pico can make some autowire decisions for you. Not clear how it scales to very large projects.

Guice - Simple to configure, you just add annotations and inherit from AbstractModule to bind things together. Scales well to large projects as configuration is kept to a minimum.

Spring - Relatively easy to configure but most examples use Spring XML as the method for configuration. Spring XML files can become very large and complex over time and take time to load. Consider using a mix of Spring and hand cranked Dependency Injection to overcome this.

Community Size

Pico - Small

Guice - Medium

Spring - Large

Experience

Pico - I haven't had much experience with Pico but it is not a widely used framework so it will be harder finding resources.

Guice - Guice is a popular framework and its focus on speed is welcome when you've got a large project that you're restarting a lot in development. I have a concern about the distributed nature of the configuration ie it's not easy to see how our whole application is put together. It's a bit like AOP in this respect.

Spring - Spring is usually my default choice. That said, the XML can become cumbersome and the resulting slowdown annoying. I often end up using a combination of hand crafted Dependency Injection and Spring. When you actually need XML based configuration, Spring XML is quite good. Spring also put a lot of effort into making other frameworks more Dependency Injection friendly which can be useful because they often use best practice when doing so (JMS, ORM, OXM, MVC etc.).

References

• Pico
• Guice
• Spring
• Spring / Guice / Pico comparison
• Another Spring / Guice performance comparison

Answer 2

The answer put up by jamie.mccrindle is actually pretty good, but I'm left confused why Spring is the default choice when it's pretty clear that superior alternatives (both Pico and Guice) are available. IMO Spring's popularity has reached it's peak and now it's currently living off the generated hype (along with all the other "me too" Spring sub projects looking to ride the Spring bandwagon).

Spring's only real advantage is community size (and quite frankly, due to the size and complexity, it's needed), but Pico and Guice don't need a huge community because their solution is much cleaner, more organized, and more elegant. Pico seems more flexible than Guice (you can use annotations in Pico, or not--it's extremely efficient). (Edit: Meant to say it's extremely flexible, not that it isn't also efficient.)

Pico's tiny size and lack of dependencies is a MAJOR win which shouldn't be understated. How many megs do you need to download to use Spring now? It's a kludgy-mess of huge jar files, with all it's dependencies. Intuitively thinking, such an efficient and "small" solution should scale and perform better than something like Spring. Is Spring's bloat really going to make it scale better? Is this bizarro world? I wouldn't make assumptions that Spring is "more scalable" until that's proven (and explained).

Sometimes creating something good (Pico/Guice) and then keeping your HANDS OFF of it instead of adding bloat and kitchen sink features with endless new versions really does work out...

Answer 3

NOTE: This is more of a comment/rant than an answer

PicoContainer is great. I'd switch back to it if they'd just fix their web sites. It's really confusing now:

• http://picocontainer.com which is the most recent, but many pages have formatting issues and a few pages don't work at all. It looks like the pages were auto-converted from the older content.
• http://picocontainer.codehaus.org/ Which seems frozen in time at version 2.10.2 - It would be really nice if the pages said something like "hey, you're looking at an old web site!"
• http://docs.codehaus.org/display/PICO/Home - A confluence wiki that documents v 1.x, but it doesn't say that anywhere on the pages!

I'm using Guice 2.x now, even though it's bigger, and it has fewer features. It was just much easier to find the documentation, and it's user group is very active. However, if the direction of Guice 3 is any indication, it looks like Guice is starting to bloat, just like Spring did way back in the early days.

Update: I posted a comment to the Pico Container folks and they've made some improvements to the web site. Much better now!

Answer 4

It is a old question but today you can consider Dagger ( https://github.com/square/dagger ) in your Android App project. Dagger does code generation on compilation time. So you get a shorter startup time and less memory usage on execution time.

Answer 5

If you're after a minimalistic DI container, you can check out Feather . Vanilla JSR-330 DI functionality only, but quite good in terms of footprint (16K, no dependencies) and performance. Works on android.

Answer 6

Although I do like PicoContainer for it's simplicity and it's lack of dependencies. I would recommend using CDI instead because it is part of the Java EE standard so you have no vendor lock-in.

In terms of intrusiveness, it's main problem is the requirement of a container and the use of a relatively empty META-INF/beans.xml file (needed to indicate that the jar is using CDI) and the use of annotations (though they are standard)

The lightweight CDI container I use for my own projects is Apache Open Web Beans. Though it took a while to figure out how to create a simple app (unlike Pico) which looks like this.

public static void main(final String[] args) {
    final ContainerLifecycle lifecycle = WebBeansContext.currentInstance()
            .getService(ContainerLifecycle.class);
    lifecycle.startApplication(null);

    final BeanManager beanManager = lifecycle.getBeanManager();
    // replace Tester with your start up class
    final Bean<?> bean = beanManager.getBeans(Tester.class).iterator()
            .next();

    final Tester b = (Tester) lifecycle.getBeanManager().getReference(bean,
            Tester.class, beanManager.createCreationalContext(bean));
    b.doInit();
}