The Java+XML Conundrum
Posted by Eitan Tue, 31 Jan 2006 13:43:00 GMT
One must applaud Bob Lee for saying what many of us never dared to: I don't get Spring. I think many of us for a long time did not grok Spring either but were afraid to say it. Everything has a reason to exist and Spring is no exception.
I believe today I grok Spring a little better than before, but I'm not sure. Below is a snapshot of my continously morphing hypothesis, as it stands today, on January 31 2006.
Spring solves a number of issues that derive from a not-as-natively-implemented feature of the Java language: closures. In smalltalk, ruby, and JavaScript, treating a method as an object is a much more common thing. And thus using a method as an object is much more commonplace. So things such as Spring's *Template classes are altogether unnecessary unless you're working in Java.
One of the end results of applying Spring to a project is a combination of Java and XML. You inevitably end up with two languages instead of one. Interestingly, this aspect of Spring is directly related to a blog I wrote recently (two weeks ago, to be exact): Skip the Compile.
There are concerns in Java that don't exist in other languages. One of them is the compile step. Removing that issue leads to Internal Domain Specific Languages, the very solution to the Java+XML conundrum.
So by attempting to grok Spring, I am coming to the conclusion that Spring is an artifact that attempts to make some of the pain of working with Java go away. It does a pretty good job in some respects (I consider the fact that we still have a bunch of XML a down-side). But when we look at other languages, specifically at Smalltalk, we see a much more elegant solution: these problems simply don't exist. Everything is written in-band. I advocate that it should be.
