鉴于Guice的热度，特转一贴，帮助大家了解Guice的风采。

没有100倍，大概10倍，但是1毫秒和10毫秒对用户来说都是一样的，就一个di就想取代spring，呵呵，你在发展spring也在发展，谁都不是静止的，只要不是革命性创新，想超越spring的可能性是微乎其微的。不过使用annotation来实现di倒觉得没有什么不妥，但是只靠速度上的这点差距是无法和spring竞争的

怎么越看越像Tapestry5的ioc实现呢，莫非殊途同归。
看来当初的猜测应验了，基于注释的ioc容器开始涌现了。

  和我一开始的担心是一样的。但是，据作者举出的demo来看，业务类里只对需要注入的地方打上“标记”（annotation），接下来在一个统一的地方对这些标记绑定依赖关系。
  spring通过配置文件构建的容器环境管理bean的注入，而guice通过这个统一的地方来构建管理bean的容器环境。在实现上是另一套思路。
  说实话，对guice感兴趣，但并不了解。对guice这个统一管理依赖关系的实现方式（Module，bind）并不满意，spring的管理方式也不是最佳方案。或许guice有更好的实现方式，这正是我所期待的。

    个人感觉可以根据不同项目不同需求来使用，在不同问题上Guice和Spring各有各的优点，如果项目中用配置文件(.xml,.properties等)来处理方便的话，个人觉得用Spring优势要大一些，如果不需要繁琐而巨大的配置文件来支撑，采用Guice吧．

既然这样的话，在类代码中使用Annotation来标注，然后再通过一个相应的配置文件来统一管理这些标记，既然这样的话，为什么不直接使用配置文件来管理类之间的依赖关系，我是觉得Annotation蛮反感的，一方面，大量使用Annotation，降低了代码的可读性，另一方面，个人觉得可降低代码的可维护性，低耦合，高内聚，使用Annotation，又将这种耦合回到了类层面上的，是否是一种倒退？

Another pass at simplifying and improving tapestry-ioc, using ideas from Guice. The idea is to combine @Inject with other annotations to supply overrding details (but @Inject on its own is usually sufficient).
这个是 tapstry主页上的

就为了按需放代码这么简单的工作
折腾出如此复杂的框架
java真是诡异的平台

今天上Google看一下Guice的DI，在我们使用Guice的时候，我们并不用具体指定具体的实现类，只需在需要注入的地方使用@Inject，Guice会自动地绑定并且注入进去，我们只需要实现
Guice的Module接口，该接口只有一个方法， void configure(com.google.inject.Binder binder);，configure方法通过binder对象将具体的实现绑定到我们需要注入的地方，蛮不错的。

我还是会使用spring。因为其他地方已经使用了spring。而且spring现在使用得非常好，没有理由切换其他的ioc上面。 而且好像spring也提供了annototion的支持。我对annototion的使用也比较反感

唉，感觉不出比spring方便的地方，也没什么新意，如果没有spring , 相比较之下还不如选择PICO.