Modern spring is amazing. Look into it. It's no longer the configuration hell it was 10 years ago. Everything is convention
Over configuration. It's easy to run and configure.
Not quite. Although i don't know C++ well enough to be sure.
Spring started life as a dependency injection framework, and that still constitutes the central part of it. Dependency injection is the mechanism by which components of an application are created and assembled, and so there was a natural expansion of Spring into providing those components. Spring now provides a web framework, plumbing for database persistence, batch processing, and all sorts of other things:
AIUI, Boost is a collection of libraries. Spring is much more frameworky than that. The general approach with Spring is to add a particular module to your project, sprinkle a few magic annotations on your code, then watch in wonder as lots of sophisticated stuff happens, exactly as Spring's designers foresaw. Usually.
There are two main alternatives to Spring. Firstly, Java EE, which is similar in spirit, smaller in extent, and the product of a decades-long standards process involving some of the world's most ponderous companies, but really not as bad as that might suggest:
And in fact, i'd describe Spring as an alternative to Java EE, rather than vice versa.
Secondly, not using a framework at all, and just putting everything together yourself. To a large extent, Dropwizard etc are the result of people doing this, then posting the reusable bits of their application to GitHub.
Java's equivalent of Boost is probably some combination of Apache Commons:
The difference is that if you're using Spring, then you are writing a Spring application. Every part of your code will be pervaded by Spring, and you will have to do things in the way Spring prescribes. If you're using Commons or Guava, your application is your own, and those libraries will crop up here and there, where you choose to use them.
They do, and I think more unsettling is the fact that they are completely serious about doing these things. The widespread use of IDEs that autocomplete probably leads to a feeling of indifference ("I don't have to type it all anyway.")
Also related is the forced convention of requiring one directory nesting level per package name component, resulting in deeply-nested mostly-empty directories that have a tendency to easily exceed filesystem limits.
Here's another ridiculous class name found in different project (AspectJ):
that's exactly what I thought. What I would like is something like those JS frameworks where you can choose what you want and generate the lib that suits your needs.
But... that's the point of Maven and other package managers. Why does it need a UI like that? Unlike JS, the tradition in Java development is to use managed dependencies rather than download JARs for everything and throw them in /lib.
Maven needs a UI because of its pathologically-verbose XML syntax. Compare a pom.xml with its Gradle equivalent...only one is designed with humans in mind.
Which is why I said "and other package managers." My point was that a UI like the one to build a custom Bootstrap download doesn't make sense in the Java world because we have package managers, unmanaged dependencies are not the norm in most projects.
Curious, what do they mean by 'micro'?