This is why we use Spring. We have confidence that it'll be supported long-term and will continue to have backing from a whole host of companies.

It's slightly different in a large enterprise environment where a service might be fairly straighforward - take in input, spit out output to some data store. But for the kind of work we do - end-to-end webapps - we'd be doing ourt clients a great disservice to sell them on a microframework with our homespun implementations of security, transactions etc. bolted on top.

Oh what do you know, yet another annotation...

I'm literally looking at the docs for @SpringBootTest

``` @SpringBootTest public class SmokeTest {

    @Autowired
    private HomeController controller;

    @Test
    public void contextLoads() throws Exception {
        ...
    }

This is case in point of what I'm saying - I highly doubt this actually spins up a full fledged app.

+ where is the controller coming from? It's not instantiated anywhere. What about it's dependencies? If I add one, this test will still compile, when in reality, the tests will all fail. (or at least, you would imagine most would) This field autoinjection approach encourages adding arbitrary dependencies with zero thought to anything - who cares, everything will just compile anyway. Meanwhile, a sane framework would force you to send in dependencies, forcing you to be smart about how to structure things and not compiling if you add a dependency to a controller but not to its test.

Also, what does @SpringBootTest actually do? How does it work? What if I need to do <anything that doesn't align with the simplest use case that the Spring devs cater to>? Who knows! "Just add the annotation, it's easy!" (but not simple - it's extremely, and extremely needlessly, complex)

> You can use whichever

Yes, and that is wrong. Even Spring devs themselves are now trying to put the field injection cat into the bag in favor of the correct constructor injection approach. They're not succeeding.

> Not at all

You say it's not wrong not to use Spring and... go on to say it's wrong to use anything but Spring. Classic Spring dev mentality, and completely disingenuously portraying things as if other frameworks like eg DropWizard isn't constituted of well maintained, well documented components. In reality, unlike Spring, frameworks like DropWizard are a collection of some of the best tools for each job, and it's both simple and easy, whereas Spring is just Spring, Spring and more Spring, and while it's easy, it's not simple- there's a lot of magic.

Anyway, we're not going to agree, and as I said, very close to 100% of Java devs and Java shops are 100% committed to Spring, so you win.

I'm just glad throughout my career I've found a few orgs who have been through the Spring grinder and realized the emperor really does have no clothes and have been open minded enough to look outside of the Spring bubble and try something else.