|
|
SpringComparison
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.
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.
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.
- You only need to use annotations when a binding type alone isn't sufficient.
- You can reuse the same annotation type across multiple bindings (@Transactional for example).
- Annotations can have attributes with values. You can bind each set of values separately to the same type if you like.
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.
Eric Burke recently ported a Spring application to Guice:
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.
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.
Sign in to add a comment
hey..its very useful.
this is awesome!
this is awesome!
Sounds cool but it would take a lot for me to move away from Spring. Spring's performance has never been a problem for me and I've always found it incredibly easy to use, more so than just about any other framework I can recall using.
Still, if I were building an app where performance were a primary concern and I needed those features I'd consider it.
I think I'll take out the performance comparison. It's the least of the reasons you should use Guice, and we should focus on usability, maintainability and developer productivity, all of which Guice excels in.
Unfortunately, I do not see any features which are absent in JBoss Seam 2.0... Can anyone tell why do we need one more IoC framework? Do Guice has any unique features?
Spring is an outstanding package and it has proven it's quality. I personally know more than 10 fortune companies use Spring as their first choice for JAVA framework. We can not sell the idea that we have a framework which is using a new concept in java technology which will reduce the configuration effort or number of codes.
I don't see anything wrong with Google's approach, but not sure your intension. If you guys are big fan of spring and feel something which you guys do not like, as a open source friendly people, it is important to work with Spring and make it more Agile.
I have also noticed there are here bench marking result popping up with "Hello World" java application. Just wanted to make sure my response in a single word "Spring is not for such drama, it is a framework proven its value in numerous applications I personally know which run 10000s of transactions per day"
Thanks
Read
http://www.javalobby.org/java/forums/t103070.html for advantages of spring over guice.
Thanks,
Shaji, 10,000 or even 100,000 transactions a day is a fairly low traffic load. You can expect that the Google guys encounter a different class of performance issues since they assuredly run in the hundreds of millions of transactions per day for Adwords. Where I work, we have some systems that will process approximately ten million payments in an evening batch operation that must be completed within 8 hours. For us, the Spring overhead is not extreme, but it is measurable. I'd be interested in trying this out just to see how it works. If there's a performance gain, all the better.
Why not unite Spring and Guice efforts and create one framework that will meet Google needs and ?
Are there any show stoppers? Spring (and Interface21) does not like Guice approach? Or Google does want to use Spring for AdWords??
Both Google and Interface21 have influenced technology world and both have good aura and attitude in developer community, why not UNITE the efforts?
Choice is good. I see a lot of the comments focusing on performance, but from what I've read thus far, I'd choose Guice for simplicity. It's nice to have a choice, and I appreciate Google keeping Guice light.
Spring too supports Java based configuration in case you find XML configuration too difficult to maintain and manage. http://static.springframework.org/spring-javaconfig/docs/1.0-m2a/reference/html/
In my particular use case, size of the application is important, as we do network deploys of the UI. in short, using spring costs us well over 1MB to achieve DI and Method Interception. Guice appears to deliver the same functionality in less than 600KB. I have yet to see how much I can prune Guice down to, but the thought of no XML files (which BREAK obfuscation/bytecode compression) is a nice thought indeed. I am aware that Spring supports Annotation based configuration, however, the raw size of the Spring library is the major inhibitor...
I suspect that I will use Guice where Guice makes sense (ie. where I just need DI & Interception), and Spring where Spring makes sense (ie. where I need a full stack).
Nice IoC-Framework. The one and only argument for guice is the performance, imho. Springframework 2.5 supports annotations as well and has many other integrations e.g. O/R-Mapping, Transaction, MVC, JMS,...
I aggree 'egieswein' : "use Guice where Guice makes sense" [..] "Spring where Spring makes sense".
I hate Spring for these boring extra features: O/R-Mapping, Transaction, MVC, JMS,...
I JUST want a IoC Framework,not a all-in-one power toy.
spring has started to look like ejb now, it is good to see DI at work but when you start to build the world and expect people to reuse that world then that becomes pain in the neck...
One more! No one yet utilized spring properly, now road diverted to one more !!!
Excellent...it is always important to think outside Spring's shell and see how can make things simpler and faster. Kudos to google
"sat down", "going forward", "end of the day"?
Did a real programmer write this, or a suit?
Really good and looking for much more of these kind for java developers.. Thanks Google.
I've written code with Guice cooperating w/ Seasar2, a DI framework which uses lesser amount of configuration XMLs. See here: (some part is in Japanese) http://anond.hatelabo.jp/20080513230840