Guice Featured Wiki Pages■Spring Comparison



How does Guice compare to Spring et al?
The Spring Framework, created by Rod Johnson, blazed the Java dependency injection trail. If not the first dependency injection framework, you can certainly credit Spring with pioneering much of what we know about dependency injection and bringing it into the mainstream. Guice might not exist (at least not this early) if not for Spring's example.

Rod Johnsonによって作られたSpringFrameworkは、Dependency Injectionを大流行させました。まして、最初のDependencyInjectionフレームワークであり、SpringがDependencyInjectionに関する知識の多くを開拓して、それをメインストリームに運び込んだことは確かに称賛することができます。 Springの例がなければ、Guiceは存在しないかもしれません(少なくともこれほど早くありませんでした)。

Guice and Spring don't compete directly. While Spring is a comprehensive stack, Guice focuses on dependency injection. Even so, the first question most people ask is, "how does Guice compare to Spring?" Rather than repeat the same spiel N times, we figured it best to answer the inevitable question once.


Let us start by saying, the Guice team has a great deal of respect for the Spring developers, community, and their overall attitude. We're more than willing to work together in any capacity. We even gave a few core Spring developers a sneak peek at Guice six months before the 1.0 release, and they've had access to the source code repository ever since.

言い習わしから始めましょう。GuiceチームはSpring開発者、共同体、および彼らの総合的な態度に対する多くの敬意を持っています。どんな状況でも十二分に一緒に働いています。 私たちは1.0リリースの6カ月前にGuiceでこそこそ覗き見をする数人のコアSpring開発者に与えさえしました、そして、彼らは以来ずっと、ソースコードリポジトリアクセス可能でした。

Without further ado, how does Guice compare to Spring?


Guice is anything but a rehash of Spring. Guice was born purely out of use cases from one of Google's biggest (in every way) applications: AdWords. We sat down and asked ourselves, how do we really want to build this application going forward? Guice enables our answer.


Guice wholly embraces annotations and generics, thereby enabling you to wire together and test objects with measurably less effort. Guice proves you can use annotations instead of error-prone, refactoring-adverse string identifiers.


Some new users fear that the number of annotations will get out of hand. Fear not. You won't have nearly as many different annotations in a Guice application as you have string identifiers in a Spring application.


1. You only need to use annotations when a binding type alone isn't sufficient.
2. You can reuse the same annotation type across multiple bindings (@Transactional for example).
3. Annotations can have attributes with values. You can bind each set of values separately to the same type if you like.

1. バインディングがあるタイプが十分でないときにだけ、アノテーションを使用する必要があるだけで。
2. 複数のバインディング(例えば、@Transactional)の向こう側に同じアノテーションタイプを再利用することができます。
3. アノテーションには値がある属性を持つことができます。 よければ、別々に同じタイプにそれぞれのセットの値を縛ることができます。

Spring supports two polar configuration styles: explicit configuration and auto-wiring. Explicit configuration is verbose but maintainable. Auto-wiring is concise but slow and not well suited to non-trivial applications. If you have 100s of developers and 100s of thousands of lines of code, auto-wiring isn't an option. Guice uses annotations to support a best-of-both-worlds approach which is concise but explicit (and maintainable).


Some critics have tried to find an analog to Spring's XML (or new Java-based configuration) in Guice. Most times, there isn't any, but sometimes you can't use annotations, and you need to manually wire up an object (a 3rd party component for example). When this comes up, you write a custom provider. A custom provider adds one level of indirection to your configuration and is roughly 1:1 with Spring's XML in complexity. The remaining majority of the time, you'll write significantly less code.

GuiceでSpringのXML(または、新しいJavaベースの構成)に対して、アナログだという批評家もいました。アノテーションは、ほとんどの場合利用出来ますが、時々使用できないときがあります。そのときは、手動でオブジェクト(例えば、サードパーティーコンポーネント)を結び付ける必要があります。これが言った場合、カスタムプロバイダーを書くことで対応が可能です。カスタムプロバイダーは、設定に1つのレベルの間接層を加えます。およそ複雑さにおいては、SpringのXMLと1:1です。 残った大部分の時間で、少しだけコードを書きます。

Eric Burke recently ported a Spring application to Guice:
エリック バークは最近GuiceのためのSpringアプリケーションをポストしました。

At the end of the day, I compared my (Guice) modules - written in Java - to my Spring XML files. The modules are significantly smaller and easier to read.
Then I realized about 3/4 of the code in my modules was unnecessary, so I stripped it out. They were reduced to just a few lines of code each.
Oftentimes, it doesn't make sense to port perfectly working code which you won't be changing any time soon to Guice, so Guice works with Spring when possible. You can bind your existing Spring beans. Guice supports AOP Alliance method interceptors which means you can use Spring's popular transaction interceptor.

結局は、私はJavaでかかれた(Guice)モジュールとSpring XMLファイルを比較しました; モジュールは、かなり小さくて読みやすいです。
次に、モジュールのうちおよそ3/4のコードが不要であるとわかったので取り除きました。 それらはそれぞれコードのわずか数行に減少しました。
たいてい、稼動しているコードをいつでもすぐGuiceに完全に移植することに納得がいくというわけではありません。そこで、GuiceはSpringと共に動作することもできます。共同で動作している場合は、既存のSpring Beanをバインドすることができます。 Guiceはその方法のために、AOP Allianceメソッド インターセプターにSpringのポピュラーなトランザクションインターセプターをサポートします。

From our experience, most AOP frameworks are too powerful for most uses and don't carry their own conceptual weight. Guice builds method interception in at the core instead of as an afterthought. This hides the mechanics of AOP from the user and lowers the learning curve. Using one object instead of a separate proxy reduces memory waste and more importantly reduces the chances of invoking a method without interceptors. Under the covers, Guice uses a separate handler for each method minimizing performance overhead. If you intercept just one method in a class, the other methods will not incur overhead.

経験上、ほとんどのAOP枠組みは、ほとんどの用途には強力過ぎるため、AOP自体の概念的な抵抗感を乗り越えられません。Guiceは後からの思いつきの代わりに、コアの中でメソッドインターセプションを組み込みます。 これは、ユーザからAOPの内部実装を隠して、学習曲線を下げます。 別々のプロキシの代わりに一つのオブジェクトを利用すればメモリ浪費を抑えるうえに、より重要なのはインターセプターなしでメソッドを呼び出してしまうという可能性を小さくすることです。内部では、Guiceは性能オーバーヘッドを最小にするハンドラーを各メソッド毎に使用します。クラスのメソッドの1つだけをインターセプトしたとしても、他のメソッドはオーバーヘッドを受けません。

Finally, we knew from the beginning that no matter how much more usable Guice is, it probably shouldn't be too much slower than alternative solutions. Back when we wrote the initial performance tests so we could track Guice's performance as development progressed, we had no idea Guice would turn out to be orders of magnitude faster than some alternatives. Guice's unique builder-style design combined with the new concurrency facilities introduced in Java 5 enables unprecedented performance, some 100X faster than Spring for dependency injection (according to this benchmark).

最終的に、始めから使用可能なGuiceの機能がどれほど多くても、おそらく代替の解決策より目に見えて遅くてはいけないでしょう。開発が進歩したときGuiceの性能を追跡することができるように初期の性能テストを書いたとしても、Guiceが大規模に他の代替手段よりも早くなると判るようなアイデアが思いつきません。Java5で導入する新しいbuilder-styleで結合されたGuiceのユニークなアーキテクトスタイルデザインは、dependency injection (このベンチマークに従って)においては、Springより数百倍速いという空前の性能を可能にします。