VMWare and Spring

VMWare bangs their bells for Spring framework, trying to tell it is best choice. Lots of people excited etc.

Now (*cracks my fingers*) questions and doubts:

1. Spring's arguments are valid. Yes, they are. With one little note: they are valid on EJB2 and JEE5, where first one has incredibly bad design, another is bulky and not really convenient. Wait a second... but we are not talking for old projects future, but for new! So, when you going to choose framework for plain new project, the we do have EJB3 and JEE6 today.
2. RedHat (also known as a leader at Enterprises in Linux world, by the way) and Snorcle (also know as Oracle, also known as benevolent dictator, also known as Sun Microsystems eater) — both of them completely don't really like Spring. In fact, they think it is a bullshit and they think JEE6 would fit to your datacenter much better.
3. Do you really like that XML thing? I think this is all like back to a stone-age, instead have just everything minimalistic and cute (means: modern).
4. Template classes as intrusive as it turns your code to a bullshit. Yes, you can have a workaround for this, but the keywords here are still stays to "bad" and "design".
5. Tell me, you configuring or you coding?.. In Spring you will code^H^H^H^Hconfigure your project in XML. Well, no, you're literally coding. You are freakin' coding in XML, don't get fooled and mislead.
   
   Let me explain here a bit: a configuration file is something like you can find in Unix /etc directory. It is a small, simple ASCII text file, you can put comments in there and you can parse it with your Perl/Python/Ruby or just AWK/Sed. This is what is called: configuration file and was more than 30 years around. Now what Spring brings you into? A pile of XML, that are actually built into your WAR file. They do believe you have to change XML, so no need to change source code of Java.
   
   But this is utterly misleading: you intrude to a deployed application anyway (sane companies will put it through a "Change Request" procedure that involves also testing and quality assurance sometimes), while configuring application means you change only that little cute file in /etc directory (or click few checkboxes in admin UI) and thus your buddy sysadmin can do that with a cigarette in his teeth with a little effort (change request still required, but a consequences are significantly smaller).
6. Spring adds complexity, it does not removes it. Don't be fooled: you will need to have a serious and difficult learning curve as well as you will need to spend weeks to configure your XML (see above).
7. Bugs in framework itself will cost you a lot. So make sure your framework is extensively supported, reviewed and updated. Who you will trust more: giants like Oracle and RedHat that has tons of very fat customers, or just a little VMWare — yet another player in virtual world with not the best business model? You choose.
8. OK, you can dismiss my XML rants by changing from XML to annotations. Great point! Because here is another problem: different ways to do the same thing. Java coders chronically away from Unix, but we already been there and we know it is called as "Tim Toady" or TMTOWTDI or "There's More Than One Way To Do It" or, simply Perl. It results to things like this or like this. In contrast, the beauty of Python language lays in its great philosophy: "There should be only one — and preferably only one — obvious way to do it".
   Little note to above: I was not talking about code obfuscation.
9. We already learned that doing often casting is a bad idea. So that's why we do have Generics for this and why we are trying to go away from casting operations as much as far as possible. However, Spring is pushing you back to a mesozoic era to fight java.lang.ClassCastException dinosaurs each next step. Stupid.
10. \u3042\u306a\u305f\u306f\u99ac\u9e7f\u3067\u3059 — this is how to say "Good morning" to your boss in Japanese (anata ha baka desu), or exactly what you will get, once you open your ResourceBundle in VIM editor.
11. It is going up to eleven... You normally should keep SQL separate from the code. Try it with Spring and see how it works (or not) for you.

Of course, the main question still around: Why bother with Spring, if JEE6:

• Is getting to be more and more lightweight than Spring 3
• Is less complicated (recently) than Spring 3
• Is well designed
• Is well documented
• Is well supported
• Is an industry standard and chosen by industry leaders (sure).
• Has more features
• Is easier to learn (because it is less complicated)
• Is not proprietary, versus Spring which is proprietary container.

I certainly don't have an answer on above. Maybe you have?

Feel free to explain. :-)