February 1st, 2006

I Don't Get "I Don't Get Spring"

My comments on this rant about the Spring Framework:
I've noticed what I consider to be a dangerous and blind increase in the rate of Spring adoption.
I wander his concern about Struts or EJB. So dramatic...
The Javadocs are unnecessarily overwhelming
It´s common to complain about the lack of documentation but if you can waste your time complaining about this.. frankly, I bet there MUST be more things to talk about.
Does all of this really belong in a user API? At least J2EE cleanly separates API from implementation.
The javadoc just comes with the docs from the source code of all the project, is it bad? It can even inspire you to investigate the implementation framework and contribute.
the XML configuration is my code, and from what I can see it often ends up constituting a lot of code, all of which is Spring-specific.
Yes, the XML represents code, configuration code, that to be generic must use the java reflection feature, where you name your object classes, no place better than in a configuration file.
All your configuration will be in one place, only what you need to care about, the name of the beans and its dependencies, not tedious scaffold repetitive code. And this knowledge about the dependencies between your objects will be consistently reused across your code.
Why would I want to express all of my dependencies in XML?
Maybe because your are using a dependency injection framework and the best way to configure some framework/tool is through configuration files, they all have it, Tomcat, Ant, Apache, Maven, EJB Containers, TestNG, several other Jakarta projects, et cetera. Now with Java 5 we can do a lot of this configuration using annotations, like xdoclet have been doing using javadocs, of course, javadoc annotation cannot be read in runtime (just to say one difference, and that´s a big one).
But there is still a world of configuration that has not this nature of configuring some specific class/method or attribute, like Aspect Oriented programming interceptors. Where would you put that all methods in classes whose name matches the "*Services" expression must be intercepted by some database transactional code?
Do I use Spring for all of my objects or just the coarse-grained ones?
Use your own good sense and experience, no framework can make this kind of decision. Do you ask your hammer how much force you will need to use every time you need to fix something?
I want to validate this stuff at compile time, load time at the latest, not while I'm running my code. Does Spring support that?
Do you know any Dependency Injection container that does that?
Doesn't the Spring configuration start to look suspiciously like writing Java code in XML? Is Spring for developers who aren't comfortable with Java? I'm not convinced adding a layer of XML makes things any simpler.
It´s only configuration code. Oks, we have CMT (J2EE docs) where Spring does interfere in your code, using AOP, but not polluting your code, but it´s still there doing lots of work. But it´s your choice to use it, or not.
Back to dependencies on Spring APIs; don't I have to call the container to create my first object (assuming the rest of the Spring-managed objects in the graph are injected)? I want some way to check that the object I'm requesting is the right type at compile time. I don't want to cast. Ever.
There is a person who never used a single Java Collections Class (before Java 5), where the classes must be generic so every parameter is a Object (the root class in Java hierarchy). Before Java 5 no java serious application could be written without a Cast, at least from some object that comes from some Collection or Map.
Do I really even need a container? In Spring you look up objects using a unique ID. I assume most developers define a String constant for the ID in their Java code. That doesn't help me keep the ID value in my java code in sync with the value in my XML. Why do I need both this ID and a container? Why use two objects when one will do? Should we really group all of this information together into a container? Do Java packages and classes not suffice?
I can´t compare in my mind java packages and classes to any kind of container (from Pico to JBoss). I´m sure this one does not need explanation.
It bothers me that I have to reference Spring implementation classes in my XML configuration. I don't care about the plumbing. In Spring's defense, I've heard they have so more concise, domain-specific XML coming in 2.0, but I haven't seen it yet. Why didn't this come up sooner?
You may have a point here, spring could work as Ant tasks are. But have you ever used Spring? I´ve never bothered about this. Maybe it´s because it´s really well documented. And imho, seeing the spring class names in the XML configuration file even makes me fell more in control, more aware of what classes/methods I´m using, I can easily check the source code if I want.
What's with all the inheritance?
Most of it are in fact realization of interfaces (only contracts, no coupling with any implementation code).
And the permutation upon permutation of long winded class names? Not my style.
Good long and intuitive class names. What does ClassPathXmlApplicationContext class does? Load from the classpath a XML application context file. My style is to write comprehensive code.
A good refactoring to the bean creation pipeline would result in easier to follow and more performant code and would enable reuse without resorting to so much inheritance.
Never heard of performance issues with Spring.
What's with auto-wiring? Does anyone actually use that, or is just another notch in the feature headboard?
It works, it´s well documented, I use it a lot with my junit test cases (@see TransactionalDAOTestCase).
How does Spring handle scopes? I heard it will finally support HTTP request and session scopes in version 2.0. I was surprised to here that it didn't support this already.
Now your talking about Spring MVC.
Let's not get into the MVC or AOP frameworks. [Un]fortunately I'm not using a dependency injection container at all at the moment.
I see...
Fortunately, simply adopting dependency injection design patterns gets you 90% of the way...
Use Spring and say that again. It really does much more than 10% of the code after adopting dependency injection design patterns.

Well, I think that´s it.