|
SpringComparison
How does Guice compare to Spring et al?
Spring ComparisonThe 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.
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
guice is good, its light weight, fast and reduces a lot of config... my only concern with it is tight-coupling with the code... also in large projects the annotated code can be a bit hard to read and its also hard to find the classes with specific annotated injections, whereas in spring it is easy to see classes and injections in the config files...
We just refactored a huge project from spring to guice and it really cleaned up the code. Everything just got loads simpler and easier to use. Also with Guice I can simply inject dependencies into loaded domain objects which is something you really need when working with rich domain models. We spent most of the time removing spring dependent code from our applications. Adding Guice was easy. I love Guice!!
Just for thought: If you have refactored your code to remove Spring, how did you design it as IoC to begin with? It seems like you have issues beyond just Spring or Guice selection and usage. Just my two cents...
Spring isn't necessarily a "comprehensive stack" which makes it sounds like Guice is some light-weight thing and Spring isn't light-weight. Spring is a loosely coupled set of modules, that can act independently or as a composition into a full framework.
Additionally, I don't think people understand the trade offs of the annotations versus XML (which Spring supports both). If you put Google annotations into your code, you are tightly coupled to Google Code. Most applications that use Spring have 0 coupling directly in the code because you do not need to put any Spring annotations into your code. Additionally Spring implements some of the JSR annotations (like JPA) so your code remains portable.
Spring's XML can be as compact as you want, ranging from varying styles supported directly by Spring to XBean.
If you waste your time and money changing frameworks for no other reason than because you love Google, than your project is losing the software war on attrition. Rest asured that your best competitors aren't going to waste their time and effort on such an activity, they're writing features the customer wants while you change annotations and XML.
It's no wonder that the (great) new Spring Application Server is GPL licensed instead of Apache 2.0 Licensed.
I love Spring, one thing I don't like about it is the Namespace configurations which have grown and changed from version to version only package/replace the old configurations. I have to try Guice yet, hoping for the best.
I am building a web application with Wicket Spring+JPA(Hibernate) technology...should i be considering the guice dependency injection as we are looking for spring only for dependency injection ..
When I use GWT to build the javascript client UI, the code size is very important. I'm choosing a extrem lightweight Ioc Container. Guice+Gin sounds great. If spring IoC could be implemented without java reflection and can be used in GWT, like Rocket project(using the same approach with spring bean factory). That should be more attractive because more people are familiar with provable spring solution in the server side.
Spring had a clear objective in mind, wipe out the old heavily loaded world of EJB and bring in IOC and also all other modules that would make it as a framework of consideration for a real world project. But it also says that is just an IOC and it upto the user choice to use Spring or any other framework. So it in a way introduced IOC to the java community.
Guice as i see it here is a "rehash to Spring"... All that one would like to know is the clear intention of Guice so that it helps out in the decision making process and would do this page justice.
I would love to see the Guice and Spring community in working towards the same goal treading the same path rather.
Any one using guice in production yet?
One problem with Spring is that it seems to provide no component-centric "front end". Spring MVC is no longer a state-of-the-art technology. Tapestry-Spring integration is not fool-proof (Tapestry5 has moved on to create its own IOC). If Spring can provide a component front end AND a fully integrated stack like JBoss Seam - that would turn the tables on EVERYONE.
@ferrypessoa
Stay tuned ;)