> First of all, I think that Spring solved some very clearly identified > problems with Jave EE, which is why it became so successful. It was > certainly not a solution in search of a problem.
Spring is so many unidentified things thrown in, that us talking about "Spring" doesn't even make sense - it's become the very definition of everything and a Kitchen Sink [1]. Just today I opened a new Spring project I had never seen before, and had to battle with 27 Spring related dependencies that it pulled it, and find the accompanying solution alternatives and configurations that goes with it. But if we just focus on dependency injection, one is better of using Guice or can even get by just using plain old service provider interface. > By solving these problems, Spring > introduced quite a few new problems and flawed processes of its own, and we > are paying the price now (100% runtime exceptions is one, but another > erosion of Java's static safety was the overall reliance on XML. It also > grew to be as complex as J2EE). I still don't think you can fault runtime exceptions for how Spring is put together, that's a red herring. It's not the compilers fault that you have robbed it of every chance of doing static analysis at compile time, by favoring runtime orchestration magic to your primary programming language. As Gosling once said "Every configuration file ends up becoming a programming language". /Casper [1] http://repo1.maven.org/maven2/org/springframework/ -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
