>what a rant

Thanks, but I can't take credit for it. I owe it all to Spring.

Dependency injection is overrated.

>XML configuration is in the past

Show me your empty -servlet.xml file!

But it is funny that you picked just one thing to eliminate. That still leaves at least 3 other approaches!

I don't have a problem with annotations per se. But when you throw them in with a hodge-podge of approaches, at some point the result is a hot mess.

>because your learning curve is steep doesn't mean that a product is bad

Oh, but it can be a pretty big hint. And, here, that's exactly what it means! It's way too kludgy, overengineered and error prone. If you start with the question, "why is the learning curve steep with this particular framework?", you should quickly realize that it's suboptimal at best. ;)

> Show me your empty -servlet.xml file!

Easy. You don't event need empty one, just in web.xml:

<servlet>

    <servlet-name>spring-dispatcher</servlet-name>

    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>

    <load-on-startup>1</load-on-startup>

    <init-param>

        <param-name>contextClass</param-name>

        <param-value>org.springframework.web.context.support.AnnotationConfigWebApplicationContext</param-value>

    </init-param>

    <init-param>

        <param-name>contextConfigLocation</param-name>

        <param-value>com.mycompany.MyConfig</param-value> <!-- annotated with @Configuration -->

    </init-param>

</servlet>

but what are you talking about? have you seen spring boot? There is no .xml file to be empty to start with. Please research technologies better before you judge them.

I am finding that less needs to be done in .xml. Instead, you can use heavily annotated classes or annotated config classes.

But, that's still awful. First, why give three different ways of doing the same thing? Provide one clean way and teach it. Is the other stuff just legacy baggage? If so, at least clean up your docs.

And, that's part of the point, right? If you have this unnecessarily large learning curve because of all this unnecessary framework cruft, then it speaks to the quality of the framework, as well as the ease of development and maintainability of the apps that use it.

Secondly, I know some people think annotations are the path to everything, but they really can be abused. At some point, you are sacrificing coherence and just introducing a lot of functionality that is not expressed through code.

And this doesn't get into the hidden gems like, "use this automagical feature and it quietly disables that other needed automagical feature". And, "add this thing that will be needed by 99% of Webapps to your config, or it won't work." Really? Then why not make it the default?

Maybe you've been using Spring for a while, so it's awfulness is no longer a big deal to you. You have adapted to it. Heck, I did the same with Struts years ago. But, I would bet that if you were starting today or if you were given a chance to work with a cleaner framework, your first thought about Spring would be "are you kidding me?"

I'm coming from Rails (7 years) and am now looking at Spring Boot - I've also experimented with Scala and Play, Scalatra, Sinatra, Go, .Net MVC, Elixir/Phoenix. I'm impressed with what I've seen so far from Spring boot. I've only got a experimental app connecting to a database and producing JSON, but no XML config yet other than my POM. I'm actually very impressed with how much code I'm not writing, which is something I've become accustomed to with Rails and was a surprise from Spring/Java.

On your point about maintainability: If you're writing a large app that you're likely to be supporting for the next 10 years, I like the idea that backwards compatibility or at least some form of lenient deprecation is in there. Once you're over 25k LOC do you really want breaking changes every framework update which require you to drop all your planned features and improvements and change all your code again?