Spring and Google Guice are two powerful dependency injection frameworks in use today. Both frameworks fully embrace the concepts of dependency injection, but each has its own way of implementing them. Discover how Guice can make your code more modular, easier to write, and less error prone to maintain.

Comparing Spring and Google Guice Containers


**************************************

Recommended Books for Learning Spring & Guice

Google Guice: Agile Lightweight Dependency Injection Framework (Firstpress) ~ Robbie Vanbrabant
Dependency Injection  ~ Dhanji R. Prasanna

Spring in Action  ~ Craig Walls
Spring Recipes: A Problem-Solution Approach  ~ Gary Mak
Professional Java Development with the Spring Framework ~ Rod Johnson PhD
Pro Java EE Spring Patterns: Best Practices and Design Strategies ~ Dhrubojyoti Kayal

**************************************

Currently plain Java is my favorite IoC container.  Nothing beats the simplicity of constructosr and getter/setter methods.  I'm so sick of seeing the guts of applications exposed through ugly XML or writing a billion annotations just to get access to a simple component.  Its all ridiculous, bloated, and most of the time unneccessary.  Anybody else fed up?

--

Bill Burke.

JBoss by Red Hat

Author: RESTFul Java with JAX-RS

 

Bill,

Remember, JBoss does exactly that with their CDI, Weld, Seam, etc. implementations. That's makes me wonder which flavor of the "stuff" you smoked today. Before I take you serious with those comments do the following:

1. Strip naked.

2. Jump on the street with a huge sign board or placard that says: "NO MORE IoC. I DON'T BELIEVE IN THE PRINCIPLES AND GOALS OF JBOSS".

3. Recite that message on your placard a 100 times. Do that very loudly to attract the maximun attention.

4. After that go to your employer and submit your resignation letter. Remember to go there naked as well.

5. Go back to your dungeon and code with only Constructors and Getters and Setters for that Hello World project.

6. When done with that project make sure you get an entry in the Guiness book of records.

What a genuis your are, Mr. Burke. Not forgetting you're a hypocrite.

Regards,

Jan

 

 

 

Hilarius

Jan, thanks for giving me a laugh and making my long day happier!  More comments inline...

 

Remember, JBoss does exactly that with their CDI, Weld, Seam, etc. implementations. That's makes me wonder which flavor of the "stuff" you smoked today. Before I take you serious with those comments do the following:

1. Strip naked.

How do you know I'm not already naked?  I do work at home 99% of the time.

2. Jump on the street with a huge sign board or placard that says: "NO MORE IoC. I DON'T BELIEVE IN THE PRINCIPLES AND GOALS OF JBOSS".

I didn't say No more IoC.  Just that I'm fed up with IoC containers.

3. Recite that message on your placard a 100 times. Do that very loudly to attract the maximun attention.

I'm good at attracting attention.  Really, its easy.  Just bash IoC, Spring, or Apache and you get lots of attention.

4. After that go to your employer and submit your resignation letter. Remember to go there naked as well.

Why do that when I could just do nothing and collect a paycheck?  I do work at home.  They'd never know!

5. Go back to your dungeon and code with only Constructors and Getters and Setters for that Hello World project.

6. When done with that project make sure you get an entry in the Guiness book of records.

What a genuis your are, Mr. Burke. Not forgetting you're a hypocrite.

Maybe I am a hypocrite.  I don't really care.  In reality I think its that I'm moody and get pissed off at extremism in all forms and end up ranting about it publicly.  If that makes me a hypocrite, so be it :)

 

Seriously though, my rant is more directed about exposing the guts of your application through declarative XML IoC containers than anything else.  I'd much rather write one big composing object that you configure through Spring, et. al. and use constructor and setter methods within the composing object's start() method.  Its much better for the user to say "I want to use Feature X" or "Turn on Feature X" then having to allocate an interceptor bean, allocate a domain bean, and set the appropriate properties on the controller bean.

Anyways, cheers!

--

Naked Bill Burke

Bill

Actually "most of the time" is maintaining and developing a project in response to changing and evolving requirements. With constantly evolving and well maintained unit tests and well desinged architecture (described in Spring's XML and backed up with annotations - not the reverse) it's possible. Starting a new project happens about once a 4 months. Maintaining existing - about 8 hrs/day.

Please tell us how to do the above with sole getters/setters and constructors?

With regards and still respect to you Bill

Grzegorz Grzybek

Remember, sometimes it's important to be nice!

There is no doubt that there is a place for IoC in the Java world. The proliferation of IoC and DI containers is clear evidence.

However, I have often heard Bill's theme reiterated - that is, sometimes there's value in going back to basics. A great deal of projects have been helped by Guice or Spring or Seam or whatever the container of choice is. Having said that, I've also seen a few that suffered from framework bloat, and could have been greatly simplified if the designers didn't see every single method call as an opportunity to inject a dependency.

 

Amen brother!

Anybody else fed up?

I can't say I'm fed up because I never really climbed on that band wagon.  I've long felt that DI is a great idea but that you don't need a container to do it for you.

I won't go so far as to say that these containers don't have benefits.  For one reuse seems to be a benefit.  But I think there has a been a popular delusion that somehow DI containers make DI possible.  That without a container, you can't use DI.

As far as annotations go, what I've found is that they are often convenient but I worry that in the long term, highly annotation dependent code will prove to be inflexible.

I never like XML heavy-ness of the first Spring versions, but love working with Guice. You don't need a DI container to write a decent application, and you certainly don't need to use it for every instantiation you'll ever do, but Guice can be a big help writing software that is more loosely coupled. To achieve the same flexibility you'd end up writing something similar anyway.

In another thread on Java EE 6 one reads 

“This series of articles introduces Contexts and Dependency Injection for Java EE (CDI), a key part of the soon to be finalized Java EE 6 platform. Standardized via JSR 299, CDI is the de-facto API for comprehensive next-generation type-safe dependency injection for Java EE. Led by Gavin King, JSR 299 aims to synthesize the best-of-breed dependency injection features from solutions like Seam, Guice and Spring while adding many useful innovations of its own.”

What a world!  Java EE 6 should be the foundation. And products like Seam, Guice and Spring should be built on that foundation. But here the relationship seem to be inverted! (in harmony with IoC?)

There is something missing here in spite of various layers of containers, JVMs, Application Servers ...

Currently plain Java is my favorite IoC container.  Nothing beats the simplicity of constructosr and getter/setter methods.  I'm so sick of seeing the guts of applications exposed through ugly XML or writing a billion annotations just to get access to a simple component.  Its all ridiculous, bloated, and most of the time unneccessary.  Anybody else fed up?

--

Bill Burke.

JBoss by Red Hat

Author: RESTFul Java with JAX-RS

 

Absolutely agree! IoC often makes development much slower without adding any values it claims to add (e.g. configuration flexibility)

Currently plain Java is my favorite IoC container.  Nothing beats the simplicity of constructosr and getter/setter methods.  I'm so sick of seeing the guts of applications exposed through ugly XML or writing a billion annotations just to get access to a simple component.  Its all ridiculous, bloated, and most of the time unneccessary.  Anybody else fed up?

--

Bill Burke.

JBoss by Red Hat

Author: RESTFul Java with JAX-RS

 

Hands up for Bill!

I agree with Bill, I can understand IoC as a mechanism for frameworks to inject configuration to your code or to manage entry points (beans) to your program because these beans need to have some kind of life cycle management.

When a framework needs to manage your objects this framework is clearly intrusive, for instance ORMs. Intrusiveness is not ever bad, for instance in ORMs automatic creation and data load of persistent-dependent objects is the kind of stuff made in heaven. Beyond of this kind of examples, sacrifying object management only to automatically be injected an stupid DataSource or similar is simply dangerous because the framework, the tool, is put on top of your code!!

IoC is based on the Hollywood principle "don't call us we call you", that is your objects are like actors not managers. Most of the time this is FALSE!!

In any program most of objects are MANAGERS of other objects and create and use other sub-managers when they need them and where they need them, an object manager cannot predict what, when and how many sub-managers are going to be needed in creation time. These sub-managers are in the same time managers of other sub-sub-managers and in the end of the command chain they are objects really working like "actors", some times these actors are objects of the Java API (String, Date) or simply objects not needed of some kind of implementation switching.

In summary I don't like very much frameworks working as managers (that is using some kind of IoC), I can tolerate this like a forced contract impossed by the framework (if I need to use it), I don't see why I must to do the same with my own code.

Because in my code most of objects have some kind of responsibility and take decisions about what other objects have to be used, most of the time the "service locator" pattern is the best approach, this is curious because IoC was invented to avoid the "service locator" pattern. In spite of I can use Spring or Guice like "service locators" the typical straightforward example of service location in these frameworks is "lookup for the MyInterface.class and one MyInterfaceImpl bean is returned", this simple stuff do not work for me, I need to locate the appropriated service object for a concrete instance almost unrelated with the service object I need, some times I need to query of the type and state of the original object to know what service object return. I know that Guice can do this kind of stuff with custom producers but in the end of the day I doing the same kind of code as custom factory classes, and with Guice I sacrifice coopling, yes COOPLING IS FINE WHEN COOPLING EXISTS, if a custom made factory object returns instances of MyInterface.class I know nothing different I'm going to find in runtime and compiler saves me from many headaches.

In summary I preffer smart service locators instead of IoC, and unfortunatelly the smartest service locators are the ones I build for my code...

Complex projects like NetBeans use extensivelly the "service locator" pattern and no very much IoC (or nothing), am I wrong?

 

Currently plain Java is my favorite IoC container.  Nothing beats the simplicity of constructosr and getter/setter methods.  I'm so sick of seeing the guts of applications exposed through ugly XML or writing a billion annotations just to get access to a simple component.  Its all ridiculous, bloated, and most of the time unneccessary.  Anybody else fed up?

--

Bill Burke.

JBoss by Red Hat

Author: RESTFul Java with JAX-RS

 

Hands up for Bill!

I agree with Bill, I can understand IoC as a mechanism for frameworks to inject configuration to your code or to manage entry points (beans) to your program because these beans need to have some kind of life cycle management.

When a framework needs to manage your objects this framework is clearly intrusive, for instance ORMs. Intrusiveness is not ever bad, for instance in ORMs automatic creation and data load of persistent-dependent objects is the kind of stuff made in heaven. Beyond of this kind of examples, sacrifying object management only to automatically be injected an stupid DataSource or similar is simply dangerous because the framework, the tool, is put on top of your code!!

IoC is based on the Hollywood principle "don't call us we call you", that is your objects are like actors not managers. Most of the time this is FALSE!!

In any program most of objects are MANAGERS of other objects and create and use other sub-managers when they need them and where they need them, an object manager cannot predict what, when and how many sub-managers are going to be needed in creation time. These sub-managers are in the same time managers of other sub-sub-managers and in the end of the command chain they are objects really working like "actors", some times these actors are objects of the Java API (String, Date) or simply objects not needed of some kind of implementation switching.

In summary I don't like very much frameworks working as managers (that is using some kind of IoC), I can tolerate this like a forced contract impossed by the framework (if I need to use it), I don't see why I must to do the same with my own code.

Because in my code most of objects have some kind of responsibility and take decisions about what other objects have to be used, most of the time the "service locator" pattern is the best approach, this is curious because IoC was invented to avoid the "service locator" pattern. In spite of I can use Spring or Guice like "service locators" the typical straightforward example of service location in these frameworks is "lookup for the MyInterface.class and one MyInterfaceImpl bean is returned", this simple stuff do not work for me, I need to locate the appropriated service object for a concrete instance almost unrelated with the service object I need, some times I need to query of the type and state of the original object to know what service object return. I know that Guice can do this kind of stuff with custom producers but in the end of the day I doing the same kind of code as custom factory classes, and with Guice I sacrifice coopling, yes COOPLING IS FINE WHEN COOPLING EXISTS, if a custom made factory object returns instances of MyInterface.class I know nothing different I'm going to find in runtime and compiler saves me from many headaches.

In summary I preffer smart service locators instead of IoC, and unfortunatelly the smartest service locators are the ones I build for my code...

Complex projects like NetBeans use extensivelly the "service locator" pattern and no very much IoC (or nothing), am I wrong?

 

Sorry duplicated post, please Cameron remove one

Currently plain Java is my favorite IoC container.  Nothing beats the simplicity of constructosr and getter/setter methods.  I'm so sick of seeing the guts of applications exposed through ugly XML or writing a billion annotations just to get access to a simple component.  Its all ridiculous, bloated, and most of the time unneccessary.  Anybody else fed up?

--

Bill Burke.

JBoss by Red Hat

Author: RESTFul Java with JAX-RS

 

What is your criteria of "simplicity"? XML in IoC container serve for the purpose of having the "code" programmatically manipulable as first class objects to heterogeneous programs rather than grammatically readable as natural language texts to English programmers. In general, code simplicity (for English programmers) sacrifices the simplicity of the code that manipulate these code and vice versa. 

 

Cameron,

Nice work. Whole-heartedly agree on the points made - exactly why CDI follows the Guice model instead of the dated Spring model while adding features like context management, interceptors, decorators, stereotypes and events that do a lot more useful things than commodity DI in a server-side application...

Also agree with Bill that DI can be overkill (only use it maybe 50% of the time myself)...

Cheers,

Reza

1. Living in the XML hell

This is an old argument, a quite easy one, it was relevant 2 years ago. Since Spring 3 as I recalled, you may use the Spring annotations to get ride of most if not all XML.

2. Eliminating reliance on String identifiers

Nice point, I would tend to agree, but I think that you can use the @autowired annotation based on type instead of name, and it will do the behavior you are researching. It doesn't bothers me much.

3. Preferring Constructor Injection

Ok... so? That's an argument to prefer Guice? Do it in Spring if you want. I still prefer a property injection.

4. Nullifying NullPointerExceptions

I really don't see how this can be an argument. Guice doesn't allows to inject null stuff, so it is better...? Come on.

5. Intruding into the domain

This is an old philosophy, Spring like Guice does intrude the domain. If you 'springify' your project, spring will prevail...

6. Replacing Spring verbosity with Guicey compactness

'Unless you use auto-wiring, which is universally discouraged on any project of scale'. No, I don't discourage auto-wiring for most stuff. Spring can be quite un-verbose.

7. Considering other advantages

'There are many other benefits Guice offers that give it advantages over Spring.... blah blah...'

Nice for you... but you didn't convince me with your arguments. It does't mean I won't try it someday.

 

 

 

I would echo Etienne's sentiments. All the arguments in the article against Spring are out-of-date. A more honest title would have been Spring 2.0 vs. Guice: The Clahs of the IOC Containers.

I would echo Etienne's sentiments. All the arguments in the article against Spring are out-of-date. A more honest title would have been Spring 2.0 vs. Guice: The Clahs of the IOC Containers.

Isn't that just giving the Springs fans a taste of their own medicine? For years we've been reading those "Why EJB is evil", "Why Java EE is bad" articles from Spring fans, and without exception, they are always about EJB 2.1. This is a technology from 2003 and was completely superseded by EJB 3.0 in 2006. Yet, Springs fans keep throwing around arguments as-if EJB 2.1 was still the latest version and as-if Java EE was still completely closed source.

What goes around, comes around...

 

Augustientje,

Good to see you around, man - the rebellious spirit as usual I see :-).

Kindest regards,

Reza

1. Living in the XML hell

This is an old argument, a quite easy one, it was relevant 2 years ago. Since Spring 3 as I recalled, you may use the Spring annotations to get ride of most if not all XML.

Yes.. I love adding all kinds of specific Spring stuff in my code. And I also love the fact that I don't need an overview of how my system works since it is spread all over the place instead of a few files.

XML is crap, but the fact that I can understand a system while looking at only a few files has a lot of value to me.

 

5. Intruding into the domain

This is an old philosophy, Spring like Guice does intrude the domain. If you 'springify' your project, spring will prevail...

With a little love and care, you can keep Spring out of most code.

6. Replacing Spring verbosity with Guicey compactness

'Unless you use auto-wiring, which is universally discouraged on any project of scale'. No, I don't discourage auto-wiring for most stuff. Spring can be quite un-verbose.

7. Considering other advantages

'There are many other benefits Guice offers that give it advantages over Spring.... blah blah...'

Nice for you... but you didn't convince me with your arguments. It does't mean I won't try it someday.

Same goes for me. Although I couldn't care less about Spring these days, I never cared about Guice at all.

1. Living in the XML hell

This is an old argument, a quite easy one, it was relevant 2 years ago. Since Spring 3 as I recalled, you may use the Spring annotations to get ride of most if not all XML.

Yes.. I love adding all kinds of specific Spring stuff in my code. And I also love the fact that I don't need an overview of how my system works since it is spread all over the place instead of a few files.

XML is crap, but the fact that I can understand a system while looking at only a few files has a lot of value to me.

-- I agree.

Totally agree!

I think one should see how much Guice is used in the Java world and how much Spring is used.

...and then ask...why?

At leas one technical reason should answer to this question...

I was going to write this, but you said it all.

How can somebody write an article criticizing something without knowing it.

Spring can be used with annotations the same way as Guice, exactly the same.

And yet, supports XML and other types of configuration.

It makes everyone happy.

Hi,

Part of me thinks, if you prefer spring and XML use that or guice and annotations use that.  All of the points in the article can be argued both ways and depends on what you are written and personal perference.

Here is mine

1. XML definitions give you complete flexibility to alter wiring of an application without having to change code, this can be advantage if you are enhancing an exist product or framework (particually if you don't have the source).  If you use annotation or code configuration (which i believe is how it works in guice) then how to you override or replace configuration to satisfy requirements.  NOTE.  I'm not a annotation or guice expert so please provide these answers so I can broaden my knowledge :-).  I do agree the refactoring is a pain with XML configurations but that is price to pay for flexibility.

You could argue that you don't want to expose the wiring and this is, of course, your choice but you could similary argue that every class and parameter be final to prevent extending existing functionality which is just crazy.  Everything has its place as do XML definitions.

 

2. I think this is a weak point, yes it is nice that you can use annotations which are handled by IDE's but ultimaly the annotation servers the same function as a string it is still a unique identifier for the injection (in the example example.pizza.PayPal).  If you are in anyway serious about creating large applications with large numbers of wiring then you need some sort of naming for packages so why doesn't the same apply to spring configuration.

 

3. I agree that nullable and required are stupid and passing null values to a constructor is also stupid.  Constructor variables should always be none null, if you want to pass null then create a new contrustor just with those arguments.  If you have values which can function with no value, or have a default value, then make then gets and sets.  e.g. connectionTimeout could be set 60 seconds in a class, it will function find with this but if you want to override it provide a setter which can override the default. 

This is my personal rule, Constructor=Required, Property=Optional

 

4. Again I agree passing and recieveing nulls is stupid but this has nothing to do with dependancy injection.  You methods, constuctors included, should ensure that whas is passed to them is correct and throw an exception otherwise (there is no guarentee you class is going to be used within an IOC).  Same applies for return values, if you should not return null but you code allows it then use assert to prevent it.

Some will disagree to this sort of "contract" coding but you always know where you, unit tests are simplified and runtime bugs are easier to indentify.

 

5. I see this as a week point, most organisation will pick a IOC framework and stick with it.  If you want to change then refactoring and retesting will be required anyway so that is all part of the effort.  Also note that XML config does not have this problem.

 

6. I don't really see how this differs in Guice as if you implement a ProductCatalog and then want to introduce a CachingProductCatalog to a class where it is being injected but leave all the other instances then you have to change all the annotations (correct me if I am wrong).  You also have the flip side that you can change the binding once and it changes everywhere, which could cause incorrect behaviour.

 

7.  I would argue the other way, Spring is not just DI but other things too, i don't know if Guice supports aspects or not but these are all things to consider.

 

In summary, pick the one you like and like working with if it satifies your needs.  Also remember that no matter what framework you use you can make mistakes or use it poorly which will create bugs and you can't blame that on the framework.

Article should be titled "Why I hate Spring- psychological essay". Problem is that thoughout the post it is pretty clear that Ryan loves Guice and ... well, hates Spring. He might have reasons but the way he ventures at the argument makes it clearly personal and not technical/objective.

This is especially apparent in the nullability point (me and my buddy Guice hate nulls). At the same time he manges to brush off argumets against Guice like they are irrelevant and are just heretic bickering against the precious and beautiful Guice. Those nasty hobbitses...

Now, it does not mean that all arguments are wrong but "Easy stuff" thread covered that pretty well. Yup, XML is painful. Yup, we would prefer something more type safe and less ... mmm... abundant. Yes, Spring can be unpredictable in initialization sequence (well, rather it is pretty well-defined but hard to keep track of). Yup, it has a number of other defficiencies. But no, mixing IoC framework with code is not OK (kinda violates the purpose). Byond this... I guess there is a point of "good enough" and a stable framework that you and your peers know is good enough even with some quirks and it takes some real advantages to switch. I'm just not sure Guice is that nor did you convince me by the "I love Guice and you should do because I do" argument.

 

So, do you mean there are no pros for Spring?

Spring is much more than a DI framework, even looking at Spring Protfolio shows lots of more useful stuff, which can not be ignored.

By the way, why don't you use Spring 3?

If you like to compare Spring 2! Just compare it with Java 1.4 compatible DI frameworks.

I've never read a more biased comparison than this. In particular the author seems to ignore that:

1. You can do DI in Spring without writing a single XML line

2. In Spring you don't have to rely on String identifiers

3. In Spring you can do constructor and/or setter injection in the same easy way

4. Spring annotations ara at least as powerful and flexible as Guice ones

You worte: "although this article may appear to be anti-Spring" ... MAY APPEAR ???

Make ma a favor: just tell me how much Google payed this article because I can't believe you are so uninformed.

 

Haven't used Guice, it's pretty good from what I have heard. However so is Spring. Really if you have to pick one, it's probably not a technical decision, more a practical one: -

(from jobserve)

IT, London, Spring, past 7 days - 346 jobs

IT, London, Guice, past 7 days - 1 job

You are right. In the short term jobmarket decides everything...

Spring Framework had almost monopoly during these last 2 years...EJB failure helped Spring ...
But this can change very fast, especially when the  face of Spring itself changes.. and other players enter the field..

Microssoft was able to 'dump' millions of Vista within a short period... but the number did not mean anything ... Visa flopped... and mS was forced to give an XP3 upgrade and then W7!  Just to emphasize that the numbers alone doesn't decide the future...

>>Moreover, as a developer I often need type checking in places an IDE can’t go, such as during continuous integration. Spring offers no help in ensuring type safety during an automated build without again requiring a tool specially written for that purpose.

Valid point, but how useful it is depends. In my past experience with Spring for over 5 years i haven't seen the need for this at all. May be i am just focused on what i am doing...

>>Replacing Spring verbosity with Guicey compactness...
....That means, if you have 50 places where you want to add a dependency, you must modify 100 declarations of that dependency: 50 source files and 50 bean definitions in one or more configuration files...

The author probably hasn't used Spring annotations. All we need to modify is the 50 source files, thats one less than the Guice :-)

>>Though Spring offers some basic support for generics by offering type-conversion for collections, its traditional reliance on XML limits its flexibility.

I have been using generics extensively for sometime and haven't ever felt Spring to be limiting. Can the author give a valid example of where generics is truly limiting? Please don't come up with a hello world example that nobody will ever use.

>>Guice is also very fast, an even more impressive feat considering that by default Guice injects a new and separate instance of an object for each dependency (called “prototype” scope by Spring), whereas Spring provides singletons by default.

We are probably talking milliseconds here (basic DI to DI comparison).

>>An outgrowth of the criticism of Spring XML is its heavy dependence on String identifiers. Because with XML you no longer have type safety, Spring only requires that you specify class names in bean definitions, with a special String identifier that is referenced throughout the rest of the XML configuration (and even in Java code).

Why is the author not willing to consider the option of using annotations wherein we don't have to specify any String identifier?

>>In Spring, classes are traditionally wired together using XML metadata. Unfortunately, wiring classes in a format other than Java means losing all the benefits of the Java compiler and type checking.

Counter-point C: Thats why Spring supports annotations.

>>Configuration is further complicated by Spring’s support for aliases, which permit you to assign multiple names to a single bean, if perchance you are wiring two systems together that reference the same bean by different names.

Excuse me, but how can an optional feature be considered a disadvantage. The author appears to be hunting for every possible thing that could be called out as a problem.

Read freaking documentation of the both product before doing comparision and wasting people's time.

As mentioned by others, the article is really just a joke. No need to comment on that.Why has the author not compared latest Guice Snapshot with Spring 0.2 beta ?

Even more interessting is Bill's comment. Not that its totally unexptected because after years following TheServerSide (and the comments), Bill is always good for a laugh.

So he doesnt like annotations. First, this is a pretty uncommon. To me annotations were one of the best inovations in java technology in 10 years or something. And when he doesnt like them, does he also avoid JAXB or JAX-WS? And what about ORM? I assume he doesnt like JPA annotations either and still stick with proprietary hibernate API and its freakin HBM files. I am pretty happy that Bill is not in my dev team.

 

Marc Logemann
http://twitter.com/logemann

Hello everyone!

Thanks for the thoughtful comments and critiques of the article.  It's nice to see this topic still generates a lot of passion and debate.

Ryan Nelson

Hello everyone!

 

Thanks for the thoughtful comments and critiques of the article.  It's nice to see this topic still generates a lot of passion and debate.

 

Ryan Nelson

 

I don't think it is nice at all.  Five years after Spring and people are *still* talking about XML hell and whether or not Spring is good.  That isn't advancement. That's beat the dust that used to be the skeleton that used to be a horse.

 

Don't like Spring don't use it or write something better. If someone didn't use it *correctly*, then fix it. This argument is tired.

We are halfway through 2010. Surely, there must be something new to talk about.

Thanks for the great article Ryan.

You certainly need thick skin to write for TSS. We're all passionate about our technology, and sometimes it's easy to get caught up all the feedback.

I know you're looking at Spring 3 features and many of the improvements Spring has made. I'll be looking forward to your next follow up article as newer versions of Spring become more prevalent in the industry.

-Cameron McKenzie

Ryan,

I second Cameron's sentiment and think you did a great job and will do a follow-up soon. Personally, I would love to see code examples for both Spring 3 and Guice to drive home the points. Sometimes, a line of code is worth a thousand words :-). And of course I'd love it if you added CDI to the comparison mix :-).

Cheers,

Reza

For anyone looking for details about all the different possible DI capabilities in the Spring framework that is now available a recorded webinar (registration required) that covers all the options:

Spring Dependency Injection Styles

In this talk, Chris Beams from SpringSource, provides a hands-on tour of the new dependency injection features in Spring 3.0. Focusing on container configuration, Chris shows by example the use of XML, Annotated POJOs, and Java @Configuration classes to wire up your application. Just as important to knowing how to configure the container, the session also discusses why you would choose one method over another, how they can be mixed and matched, and how a global view of the application can be viewed inside SpringSource Tool Suite.

I have summarized my comments here: XML in IoC containers: A hell or realm? 

thanks for the summary Jin..it helps us a lot in sell sheet design

hey Ke Jin..thanks for the summary

vintage celebs