Really? Obviously no single class is that ridiculous (hence the title of the linked article). But that nonsense is pervasive in Java, and largely driven by the standard libraries (less so the core stuff as the more peripheral layers). I specifically remembering Swing being introduced with all the MFC goodness and noticing that they'd defined and implemented a "Model" class to track state for ... a button.
You won't find anywhere near this level of abstraction in the standard library, at least not that I am aware. The Java culture is understandably implicated by this though, because Spring is not some niche framework being perpetrated in some fringe corner of the Java-verse. It is very much the mainstream of Enterprise Java. Of course there are lots of Java developers outside of that set who are doing great work. And a lot of Spring makes sense, or at least it did 8 years ago when I last looked it. This class does seem to reference a sort of endless abstraction maze that resonates with people though.
Last I checked, the standard library wasn't trying to implement an IoC container. Your comment is actually fairly amusing, given that Spring was developed originally as an answer to the overly abstract mess that was the original version of Enterprise JavaBeans.
Interestingly, things like @Inject came after Spring, and were inspired by Spring and a number of other containers.
I was just referring to the standard library in J2SE. Of course it isn't trying to do an IoC container - but there was a comment above about whether or not this is a "Java" issue and it really is not. My last contact with this was before EJB 3 so I wouldn't even try to speak to how Spring and J2EE have evolved to help manage complexity.
I found it troubling for someone to equate one class or a few classes to the whole library, the whole language, or the whole community. Those pervasive nonsense you claimed in Java have certainly work very well and been used to build many systems.
