If you use Spring to manage your beans, and you do not use an init method or implement InitializingBean for its afterPropertiesSet check, and you get a RuntimeException because of that, then you fail. Period. The error is on you. Don’t blame Spring for your failure. The same would happen if you used “new” and forgot to give an actual reference to your pet constructor.

@Autowired
IFooDao fooDao = DaoFactory.getFooDao(); // or new FooDaoImpl(), or whatever

If the field is injected by Spring, the default value is not set. The opposite is true, too : is Spring doesn’ inject the field, guess what, your program will use the standart, manually initialized value.
By doing so, your programm can run whether Spring is available or not. That’s what I call non-invasiveness !

@Sadache : nice post, I think you underestimate the amount of “I love/I hate Spring”. I really appreciate the comments, still interesting.
There’s also another subject that you should have a look : “Do I still need Spring IoC when I write EJB3.1 apps only?” There was a nice presentation at Devoxx 2008, I’ll send you the link by mail.

I just read the entire article, and I fail to see how I am not correct, unless it is simply a misunderstanding due to the medium being used for idea exchange (As Sadache so astutely pointed out, I have not posted any interaction diagrams in this text-only forum).

What I have found is that in general, using interfaces just to be flexible is a waste of resources and unnecessarily bloats the code. The majority of the code you write for most projects is domain specific, task specific, and is highly unlikely to be reused.
In the event that code IS targeted for reuse, it’s not very hard to abstract an interface (hell, most IDEs can do it with a single click of the mouse!).
What’s more, larger code reuse efforts in the business world involve taking business or data logic and centralizing it via distributed interfaces. This happens after it’s discovered that multiple projects by different teams are doing essentially the same thing, and it’s ALWAYS implemented differently in different projects. You’d be hard pressed to have such intricate control over the designs in your software house that you’d catch these things, unless you became such a micro-manager that all of your developers quit in disgust.

Sticking to concrete classes but using DI for wiring gets you halfway to full code portability while at the same time reducing boilerplate and ugly service finders that shouldn’t be in your unrelated code. Making it fully portable is a simple matter of making an abstraction that matches the common behavior between the existing implementation and the new extra implementation, making a few changes using the many refactoring tools of your IDE, and recompiling. Usually this takes me no more than half an hour.

The article’s complaints about having to at least recompile the Button module don’t apply to dynamically linked languages like Java and C#, so you’re only left with having to change Button if the PUBLIC INTERFACE of Lamp changes, an unlikely scenario indeed, and once again mitigated by refactoring tools.

Use sound design principles that match the circumstances. Only add indirection if you have compelling evidence that you’ll need it in the future and the cost of doing it now will be considerably less. 100% flexible code results in a programming language.

I get pimples when exposed to 25klos xml configuration. You love it? Well, you may, but you loose lots of stuff the javacc makes you bleed for.
In my eyes it is a silly idea to use the “simple” frameworks.
Even the sort of – well let me call it interesting – EJB spec seems light weight compared to the weight Spring imposes on me (okay, EJB is for RPC only, however …).

@cyrill: To say it in a nice manner: If your shop has no discipline, it has no discipline. Full Stop. And good luck when checking discipline in 25klos xml configuration!
@cyrill: IOC was discussed long time BEFORE spring, though it was named another way – If I’m right it started out with DIP (http://www.objectmentor.com/resources/articles/dip.pdf). Thanks to Fowler every name changes :-(. You can do IOC with and without containers. Actually try to rewrite your code WITHOUT Spring and you will be surprised, how much easier it is to comperehend, and most probably even shorter in length.

@sadache: It’s the Java “Architects” that love stuff like Spring. Did you know, you do not have to know Java programming to become a “Architect”. Try to talk to them about nice stuff, like constructing your main application by healthy sized apps, ACID and CAP. Nogo. Or try to make them apply (in contrast to only naming) simple design, architecture or documentation rules and they will fail.

@wolter: You are , well, I’d say, not fully correct. Please check the link above (DIP).

@evan: You can do this all with good plain old Java and core Java APIs. Just give it a try. And please compare the 25 klos xml with the size of the additional glue code. The glue code will be shorter.

@dizzy: Well, sort of funny. That sort of answer the same way, whenever I am asked about a weakness: “Well, it isn’t that bad if only …”. Your answer states that it is bad.

@Sakuraba: No, spring was not the first Java IoC framework. I was once forced to use Avalon(http://avalon.apache.org/closed.html) …

####################
THAT SAID: Just give good plain old Java a try. You’ll be surprised, how good it fits.
####################

Thank you for this post.

Regards

John

Unfortunately I will be mistaken whatever I comment on your example. I know nothing about your business context which I consider essential for any design or architecture.
Again, what you gave as information is about the static structure and not runtime behavior. You know class diagram vs object diagram and sequence diagram.

No, it is not a lot of work, for one class. Dozens, hundreds, or thousands of classes, yes, that is too much work and a far worse smell than (constructor-injected) DI. Other users of your library either have to have access to your source (or you have to write very explicit javadocs) to know in what contexts to use what constructors. Plus, whereas Spring “magic” might lead to runtime NPE (again, 100% avoidable with constructor injection), in your example you can also create situations where the use of the wrong constructor might actually succeed, altering production context or data, when it is not intended. That is far worse, and far more likely to happen unless you have extremely tight control over every coder in your team.

You do not need to make the unit tests targeted constructors public, just keep them package private.
Inside the package itself, well that is a less important concern, and indeed you can either add JavaDoc (which is a good practice) or use annotations to generate warnings.
Constructors allow you to use final fields which guaranteed no mutation to your objects’ state when necessary (IMO always).

Yes, because multiple situational constructors is mandatory and explicitly type checked, and does not require any extra conceptual or cultural baggage on the part of users or developers. In addition to the above, there is also no way for a new developer on your team to know which (and how) properties are set other than to walk the constructor chain of each dependency. That sounds like a recipe for failure for any but the smallest, most tightly controlled culture teams.

You do not need to follow constructors chain. At each level of composition a parameterless constructor sets its dependencies for production. So for instance if you want to know what is your EmployerSalleryCalculator depending on, well you see the parameterless constructor. Of course now you can ask yourself further questions about the composition of its components, but you know again where to find it. Each concrete class is responsible for specifying its dependencies. Isn’t that the single responsibility and separation of concerns principle? I am afraid Spring does not follow the principle…
And by the way, you have never had to walk dependencies chains in different Spring configurations files? I am sure constructors are more navigable. Everyone got ctrl+click!

versus your magic constructors that can succeed long enough to cause damage

I am afraid I didn’t get your argument. You mean you can not change at runtime what is @AutoWrapp ed? When as I told you can control the visibility of your constructors and expose only parameterless ones.

It takes about 30 seconds to find the Guice project site, which contains numerous references.

I am not doubting the success of projects based on Guice or DI in general. I am just sure there are a lot a lot of projects that succeed with no DI.

From your argument I could understand that you are for Constructor Injection which is good. But then you try to show that constructors are bad (where as I described above, I disagree with you). So what are you for?

BTW: I like what Guice states
Wherever possible, use constructor injection to create immutable objects. Immutable objects are simple, shareable, and can be composed

1) 100% avoidable with constructor injection.

>Now did it happen to you to forget to declare or mistype your beans in your config? What happens? Runtime exception! What? I thought Java applications are statically typed!

2) A huge problem with Spring XML, but not with DI in general. Guice, as others have pointed out, has no such problem, nor does Spring JavaConfig.

>Loose coupling is a fruit of good design and architecture, and Spring, DI or IoC have nothing to do with that. For testability and loose coupling I can have two constructors, one parameterless that specifies “DAO” dependencies for production code, and another with parameters to be used when testing. Did that look like a lot of work?

No, it is not a lot of work, for one class. Dozens, hundreds, or thousands of classes, yes, that is too much work and a far worse smell than (constructor-injected) DI. Other users of your library either have to have access to your source (or you have to write very explicit javadocs) to know in what contexts to use what constructors. Plus, whereas Spring “magic” might lead to runtime NPE (again, 100% avoidable with constructor injection), in your example you can also create situations where the use of the wrong constructor might actually succeed, altering production context or data, when it is not intended. That is far worse, and far more likely to happen unless you have extremely tight control over every coder in your team. Externalizing these things in properties files? Congratulations, you may not want to call it that, but properties files are conceptually similar to DI. (As you say, DI is not rocket science — it is just handing an object its dependencies.) And back to testing, this way also presents you much more work to perform integration testing of several classes in concert, since you have to construct the proper constructor chain for every object in the test, every time, for every such test. If DI is a smell, this is a fetid stench.

>Now I can hear you, use annotations! Annotations solves your problem! Well I am afraid not. Annotations like @Required or @AutoWired is just like begging the user not delete the field or property, and it is not mandatory and not forced by any checker. Remember, I am talking culture here…
Yes, because multiple situational constructors is mandatory and explicitly type checked, and does not require any extra conceptual or cultural baggage on the part of users or developers. :) In addition to the above, there is also no way for a new developer on your team to know which (and how) properties are set other than to walk the constructor chain of each dependency. That sounds like a recipe for failure for any but the smallest, most tightly controlled culture teams. I will not take Spring XML given the choice, but if I had to choose between ugly XML and classes with @Required that fail only at runtime at startup, versus your magic constructors that can succeed long enough to cause damage, I will take the ugly XML every time. Sorry, but your solution solves one problem by creating a far worse one.

>I guess this is an over exaggerated argument, can you explain more or point me to links?

It takes about 30 seconds to find the Guice project site, which contains numerous references. Most of the Bob Lee’s explanation about Guice’s role in AdWords and at Google are in the linked videos, so it is hard to quote here. Here is a summary quote, from the Spring comparison page:
http://code.google.com/p/google-guice/wiki/SpringComparison

“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. ”

>OOP is about relationships between instances not between classes. Spring emphasizes classes and ignores so much instances. I know you can use “prototype” but you do it in a much of a static way (because Spring configuration files are static).

Spring manages relationships between instances, and, while you are correct that the most common Spring case is managing single instances of service classes (effectively, though not literally, singletons), Spring has had more options than “singleton”/prototype for a couple of years now. It ships with support for request, session, and global session, and provides you the ability to define your own custom scopes as required.
http://static.springframework.org/spring/docs/2.0.x/reference/beans.html#beans-factory-scopes

Don’t get me wrong — Spring is heavy, and not appropriate for many places where people blindly plug it in. I agree that despite claims of it being “non-intrusive,” it does encourage a certain style in your code, which is intrusion, in a way. There are oodles of projects where I would not use Spring, and some where I would not use DI. But this blog entry sets up strawmen arguments using outdated information and presents even worse solutions.

I’m not quite sure I follow here… Some things simply are class relationships. For example:

bean logger:
- property logDao, ref logDao
- property currentUser, ref currentUserProxy
- property userDao, ref userDao
- property properties, ref primaryProperties

bean logPurger:
- property logDao, ref logDao
- property properties, ref primaryProperties

In this case, it makes sense to have one logger and one log purger. So many of these objects have an instantiation lifetime AND relationship lifetime that is equivalent to the running time of the program, so singleton makes sense.

The current user IS dynamic, but since the user data could reside in different dynamic data pools depending on how you access the system (via web, command line, TCP/IP link with some custom credentials and session mechanism and such, I ended up making this a proxy class that seeks out where the true data is stored.
In this case, I’m not sure how it could have been done differently. The current user has a MUCH shorter lifespan than the business objects + a few services that need to know about it, so it would make sense to have a long-lived proxy service that does the legwork of finding the information about the shorter-lived data.

On the web interface side, you have a LOT of short lived objects that present the view to the user. These objects make use of business and services, but are short-lived themselves:

operations job editor (not singleton):
- property localization, ref masterLocalization (references a singleton)
- property operationsJobBusiness, ref operationsJobBusiness (references a singleton)
- property log, ref logger (references a singleton)
- property table, ref operationsJobTable (not singleton)
- property editRequestor, ref operationsJobEditRequestor (not singleton)

Any time the UI requests the job editor screen, it gets a new instance. It makes use of some complex UI components which are built on-the-fly and added via spring. When the user leaves the screen, the editor and any non-singletons it uses are dereferenced.

I chose not to autowire in this project for fear that it would make for some very difficult-to-find null references, but I’m starting to think that perhaps a hybrid approach would work well: autowiring for long-lived singleton references, specific wiring for short-lived stuff.

Now, doing all this in an xml file is definitely not the nicest way to do things, which is why I point to the deficiencies in the Java language, rather than the concept itself. Direct language support for managing dynamic relationships and configuration without loads of boilerplate would be very nice, indeed.