You are viewing bpfurtado

Previous Entry | Next Entry

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.

Tags:

Comments

( 4 comments — Leave a comment )
(Anonymous)
Feb. 1st, 2006 03:01 pm (UTC)
Why would I want to express all of my dependencies in XML?
I don't think you really answered the question. Consider it this way: why XML, and not just create a GenericApplicationContext, and call the appropriate methods directly? After all, this is all XML*Context does, after it parses the xml. With a few helper methods, this can be more concise than xml, and doesn't get a performance hit re-reading files during unit tests (for example). The only argument left for XML is runtime reloading, which you could still get with (eg) Janino. Other frameworks use xml, true, but they aren't happy campers: maven's jelly is seen by its author as a mistake. The benefits of spring are orthogonal to its use of XML. - Baz
bpfurtado
Feb. 1st, 2006 11:47 pm (UTC)
I don't think you really answered the question. Consider it this way: why XML, and not just create a GenericApplicationContext, and call the appropriate methods directly? After all, this is all XML*Context does, after it parses the xml.
The way you put the parsing of a XML means nothing, it´s just a simple unnecessary step.
The only difference I see here is the possible IDE code completion feature which can also be fully achieved with a simple XML good old DTD file or perhaps a Schema. And I´ve seen Eclipse plugins like Spindle that can even add semantic code completion to your XML elements attributes. For example it only offers completion based on classnames in your project´s classpath that realizes some specific interface, also I´ve never seen one plugin that interferes on Eclipse Java language code completion this way, and I doubt it´s easier to do such a plugin than one based on one XML editor.
Said that a XML configuration file can be at least easy to manage than java code, or easier (with good IDE support).
With a few helper methods, this can be more concise than xml, and doesn't get a performance hit re-reading files during unit tests (for example).
Please show some performance issue, some benchmarks.
The only argument left for XML is runtime reloading, which you could still get with (eg) Janino.
Where would put Janino´s input? The text it interprets and compile to java byte code and execute? Perhaps in some static constants? or a configuration file? a xml?
Other frameworks use xml, true, but they aren't happy campers: maven's jelly is seen by its author as a mistake.
One single example among so many projects. And I don´t know jelly´s authors arguments, a link would be appreciated.
The benefits of spring are orthogonal to its use of XML
Indeed. But I think it´s XML configuration file format only helps. For all the reasons already commented.
(Anonymous)
Oct. 24th, 2007 07:42 pm (UTC)
Performance of Spring
Spring is not so fast. Reading from a file is not fast. Reading XML is rather slow depending on how you read it and Spring is not really that fast at it.

Also Sping configuration files for a program of more than 1000 files is rather cumbersome to use really slow to load.
bpfurtado
Oct. 24th, 2007 11:18 pm (UTC)
Re: Performance of Spring
That I have never heard.

How slow is Spring for you? Perhaps you are trying to use it in an embedded system? Because other than that the load time of Spring can't be noted as it's mostly used on the server side, where any webserver or application server will take ages to start up comparing to Spring.

Remember, Spring is called a light-weight container for some reason.
( 4 comments — Leave a comment )

Latest Month

January 2014
S M T W T F S
   1234
567891011
12131415161718
19202122232425
262728293031 

Tags

Powered by LiveJournal.com
Designed by Tiffany Chow