Bindings, Platforms, and Innovation
This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.
Tracking change and innovation in the enterprise software development community
Posted by Rob Thornton on Mar 27, 2007 01:00 PM
Now that the dust has settled a bit from the initial release of Guice, the comparisons with Spring IoC and specifically with Spring JavaConfig are available. Guice and JavaConfig offer different approaches on putting IoC configuration into code using Java annotations.
Spring JavaConfig, which is currently at a 1.0 Milestone 1 release, is based on the sam idea as Guice in that moving away from XML configuration and towards annotations is good in that it puts the knowledge of the configuration closer to the code. Tapestry's IoC container is designed along the same lines.
JavaConfig and Guice come from very similar backgrounds. In fact, Bob Lee has written about their history:
I also have a slightly interesting anecdote: in the very early days, Guice looked very much like Spring's JavaConfig, which isn't surprising considering Rod showed me Spring's JavaConfig almost a year ago (and I showed him Guice about 6 months ago). Just like with JavaConfig, you wrote explicit Java code to wire your objects. I originally introduced @Inject as an optional way to double-check that the external code called all your setters as expected. Once we had @Inject, I asked, why do we need to write explicit wiring code at all? Shortly thereafter, we had the Guice you all know today.
Several posts comment on the differences between Guice and JavaConfig. Debasish Ghosh sums it up nicely when he writes:
The main difference between Guice and Spring lies in the philosophy of how they both look at dependencies and configuration. Spring preaches the non-invasive approach and takes a completely externalized view towards object dependencies. In Spring, you can either wire up dependencies using XML or Spring JavaConfig or Groovy-Spring DSL or some other option like using Spring-annotations. But irrespective of the techniques you use, dependencies are always externalized.
Guice, on the other hand, treats configuration as a first class citizen of your application model and allows them right into your domain model code. Guice modules indicate what to inject, while annotations indicate where to inject. You annotate the class itself with the injections (through @Inject annotation). The drawback (if you consider it to be one) is that you have to import com.google.inject.* within your domain model. But it ensures locality of intentions, explicit semantics of insitu injections through metadata programming.
Through numerous comment threads on these posts you find that the philisophical difference is the biggest thing to be aware of when making a choice between these two frameworks. How close to your code do you want your injections to be? With Guice, your code will be tied to the container, which some people will like an some won't. Guice claims to be faster, however it is noted that Spring's IoC container (whether JavaConfig or otherwise) allows for a full range of hooks that Guice does not. Spring also offers much more than IoC, while Guice does not try to solve such large problems.
Adobe® Rich Internet Application Project Portal
Effective Management of Static Analysis Vulnerabilities and Defects
Ensuring Code Quality in Multi-threaded Applications
Besides this two, there is Spring-Annotations too ...:
It has moved to a new home, but still in active development
Spring-Annotations, it uses the Spring Framework engine, but enables all the configuration to be made using annotations
for example:
<bean id="test" class="br.com.test...." auto-wire="byName"/>
is equivalent to @Bean(name="test") in the class ...
Guice seems like a mix of Spring's "byType" autowiring with a mandatory @Required annotation (which is optional), plus Spring-annotation's automatic classpath scanning ability. I mean, you take Spring, take all its power and flexibility away, put one (nice) little new feature in, say it's from Google, and that's it, you have now a Spring killer! Whatever...
I was confused and thought JavaConfig was yet another IoC framework... Adding "Spring" in front of "JavaConfig" would make it clearer...
This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.
This article explores the use of JBoss and jBPM to implement design solutions that effectively address the issue of orchestrating long running activities.
This presentation covers the use of graph databases as an optimal solution for data that is difficult to fit in static tables, rapidly evolving data or data that has a lot of optional attributes.
This session introduces Real Options and shows how it can help in running your project. Real Options is a decision-making process that can be used to manage risk.
This article discusses the use of bindings on services and references (including the instance of non-configured bindings) as the means to implement SCA communications in a Web and SOA environment.
After a short introduction to DSLs, Scott Davis plays with the keyboard showing how to approach the creation of a DSL by typing working snippets of Groovy code that get executed.
IBM Rational and InfoQ present, Scaling Agile with C/ALM, an eBook showing organizations how to become “finely tuned software delivery machines” by enabling team integration and scaling.
Amanda Laucher presents a real life enterprise application written in F#. She shows actual code snippets, explaining design decisions and suggesting how to use some of the F# constructs.
3 comments
Watch Thread Reply