|
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 ;)
What's the equivalent of Spring 3's @Property for property injection? That's pretty handy.
Wicket is much better than Tapestry! Wicket+Guice FTW!
Apache Wicket + Guice is great.
How are we going to handle security ? Spring has a build-in security framework
@altuga
I'm using Wicket + Spring, but keep thinking about switching to Guice. However, I'm not using Spring Security, and have instead gone with Apache Shiro. Check it out, it might meet your needs.
Thanks.
is there any reference open source implementation that uses Guice, i'd like to take a look at how code looks like?
thanks, Sergiu
Spring XML files, files after files, after files ... I would do anything to get rid of them, looks like Guice is for the rescue.
I don't bind to the idea of using Guice in Unit testing. I don't want to replicate my points here so you can see at: http://stackoverflow.com/questions/2044991/what-is-the-best-way-to-use-guice-and-jmock-together/2604837#2604837 And http://www.ibm.com/developerworks/library/j-guice.html
Guice is taking DI approach at annotation level is too ad-hoc to be considered as a framework DI. At Unit test, you might want that flexibility. But at production server, you might want to deploy a suite of dependencies representing for a specific environment rather than mix different dependencies with each other. This is where xml base DI container by Spring comes to handy.
I still need to do more research before saying annotation based DI is good or bad.
Just some thoughts.
It's a complete mystery to me why you'd use Guice over Spring. The arugment that Spring doesn't return type-safe instances is bogus - if you're doing DI properly, you should never have to cast an interface to a specific class implementation anyway. The bigger issue to me is that Guice breaks one of the core tenets of DI; i.e. you should never have to modify the class you want to dependency inject. Since you need to put the @Inject keyword all over the place, it fails at that. How exactly would you use Guice to depencency inject a class that you didn't write and that doesn't already have the Guice annotations?
@sicconaets: I agree 100%.
@sicconaets for this problem they created the @provider annotation, to mark a method that creates and configures an instance of the required type.
My research on annotation based DI was done and it results to a paper published on TheServerSite?.com
You are encouraged to take a look http://www.theserverside.com/discussions/thread.tss?thread_id=60326
DI spring is a winner hands down but it could be because people like myself are used to doing things a different way or the spring way :) but Scope that I do not see many people talking about is awsome . I have used Seam and like that as well but Guice surely nails that and funny no body has said any thing about scope . I might just choose Guice just for scope .
"How does Guice compare to Spring et al?" Where are the "et al" comparisons. I'd really like to see a 'guice compared to pico'. It seems like the goals of guice and pico are much more similar. I like that I don't need the @inject annotation for pico injection - which means you can inject code from third party libraries without creating a provider. Would someone familiar with pico please tell us how guice is better?
@cam.morris You do not need @Inject for Guice either.
The advantage of Spring over Guice is that Spring is a complete framework. With libraries to do almost everything you can think of. You can start by including only the DI library and benefit from it like you would do by using Guice. But further on, you can "plug in" JPA, security, web MVC (Restful), OSGi, messaging, batch processing, etc.
@monzonj you maybe didn't notice that the the number of 3rd party modules integration (even if in some cases not supported directly by Google Guice team) is getting larger and larger every day; take a look at http://code.google.com/p/google-guice/wiki/3rdPartyModules and take in consideration that there a lot not enlisted yet, also in Apache we adopted Guice in projects like Wiket, Maven3, BeanValidation? and MyBatis? (formerly Apache MyBatis?).
@monzonj: Arguably, the advantage of Guice over Spring is that it is not a complete framework. Again, it depends on what you're trying to do. For many apps, Spring is essentially required. For many others, though, it adds a lot of complexity and a learning curve that is not helpful.
@sicconaet: Agreed about breaking DI tenets, but to me, an explicit indication of where something will be injected is incredibly helpful when working with someone else's code or with code I wrote long ago.
IMO, guice's weakness is that it doesn't support XML configuration files at all. With Spring, you have a choice. You can go for in-code configuration, where you do all the wiring in a class (which is IMO more comprehensible than guice annotations, and still perfectly testable by the compiler, from the POV of type safety), you can use annotations for doing the wiring (admittedly, less powerful than what guice provides), or you can just use plain old XML files. With guice, somebody else already made the choice for you: it has to be annotations all the way. You don't have an option even for classes you don't own and which you can't annotate. You just have a workaround: the @provider annotation.
It is probably significantly faster to start up a guice application, since all the interpretation of dependency information can happen at compile time, whereas with Spring, gathering and merging the dependency information from all the various places where it might hide might take a while. But I don't expect significant performance differences after startup, for guice and spring applications doing the same thing, since the only significant difference, once the wiring is done, is how aspects are applied (as far as I can understand this) - you simply have more calls placed on the stack with spring, but essentially the same code is executed. Since both frameworks are used mainly for server-based apps, I don't see this as a significant advantage for guice.
I also don't see spring's comprehensive technology stack as a significant advantage either. Besides transaction management and generic AOP for logging, I usually don't use much more than spring core, since (again, somebody else said it already) their UI-related components are outdated, and (as far as I know) there is no ready-made JSON-RPC server-side component in the spring technology stack. Besides, you can easily integrate non-Spring components for various jobs in your application - via the XML files, if you find better solutions than what the spring technology stack provides.
For me, all things considered, the signficant argument for spring and against guice is that I frequently have to include classes for which I don't control the source code, and where I can't add annotations by hand. A strictly annotation-based mechanism in such a case is IMO less convenient.
Just my two cents.
Actually Guice's programmatic approach (ie. Modules) and the SPI and custom injection added in 3.0 makes it easy to support alternative metadata, such as XML. As a proof of this, Guice replaced Plexus (an XML based container a bit like Spring) in Maven3 while maintaining full compatibility with plugins that had no Java5 annotations. It scrapes dependency details from Plexus XML and uses Modules to programmatically feed them into Guice, the SPI to perform analysis, and custom injection to wire everything up.
We're now actively using Guice to mimic a variety of different IoC containers, allowing us to re-use legacy components across different applications on a common framework and gradually migrate them to the JSR330 @Inject standard.
very good. The only thing guice lacks is spring.