No, there's a direct relationship between the architecture astronauts and Java-the-languages. Since Java is so simple and so lacking in abstraction mechanisms compared to almost anything else, you end up writing FactoryFactories and all the facades and all that code goop just to get any sort of halfway decent abstraction out of the language. Even things like the AOP libraries that directly muck with JVM bytecode are a direct consequence of the fact that Java-the-language is so brain-dead that it's actually easier for them to directly fiddle with bytecode than work at the Java-language level.

This lack of abstraction mechanisms was by design; it was supposed to be simpler than C++, and it is. Unfortunately, it came from an era where people still thought OO was the uberparadigm and it met every need in it simplest form. I think I can safely close the book on that as being false; at the very least you need OO with borrowed features from older-generation functional languages like closures and first-class functions, like Python or Ruby.

I do understand why there was a need for all these abstractions, but I just think it got way out of hand. "Programming" java became more about gluing frameworks together using XML than about writing code. The culture of enterprise java programmers directed people to bring in all these abstractions, "just in case" they might need them in the future. The language may be neutered, but the over-architects took the last bit of fun out of it.

I've really only been viewing this from the deployment side for quite a while, but when I'm trying to help you troubleshoot your relatively simple webapp, and I have thousands of lines of stacktraces that bubbled up through a half dozen frameworks, it's hard to blame just the language.

On the other hand, the last half decade shows a major improvement in the Java community.

Have you tried Java EE6 (the app-servers that support Java EE6 or just the subset of Java EE6 have improved significantly as well via OSGi).