> I'm in an enterprise and have successfully lobbied people to use anything other than Spring.

I was in a team that used Spring Boot for a greenfield project. The documentation was great, there was tons of help of Stackoverflow (as it's Spring) and the consideration given to testing was first class. Deployment was also easy, as we just created a fat JAR. No application server necessary.

It was a great place to work.

I have also been in multiple organizations where Spring was used, including "modern" Spring Boot and greenfield projects, and people who knew every nook and cranny of Spring.

I don't agree with any of the things you bring up.

Spring documentation is and has always been poor and the sheer volume of outdated documentation (let alone ways to do the same thing) makes it needlessly difficult to find an answer to any given question.

Differences between the real app and real http requests to the app, and using the Spring test application context and Spring HTTP tests, result in tests misleadingly passing when things are actually broken. (or vice versa)

This is different to eg DropWizard where you actually boot the app (no different to how it does in a real env ie no "test application context") and make real http requests to it. (not some watered down fake Spring HTTP test requests)

Ability to deploy a standalone jar without the need for an application server is hardly unique to Spring.

Add in the horribly, horribly ingrained, unidiomatic ways people use Spring (eg sprinkling field autowiring all over the place instead of instead of using constructor injection) etc etc and every codebase is quickly completely ruined vs if it had been implemented in literally any other framework.

But! Fortunately for you, the Java community has made their choice, and it's not going to change - Spring is the default and correct option, and anyone who uses any other framework is just stubborn and wrong.

> Spring documentation is and has always been poor and the sheer volume of outdated documentation

Spring documentation is excellent. I had to learn Spring as a PHP developer, so I put the documentation onto a Kindle and read it. It's also versioned, so you don't need to read out of date versions:

https://docs.spring.io/spring-framework/docs/

> This is different to eg DropWizard where you actually boot the app (no different to how it does in a real env ie no "test application context") and make real http requests to it. (not some watered down fake Spring HTTP test requests)

Spring Boot allows you to write full application tests that will boot it up on a random port with the @SpringBootTest annotation, as is covered by the excellent documentation

https://spring.io/guides/gs/testing-web/

> Add in the horribly, horribly ingrained, unidiomatic ways people use Spring (eg sprinkling field autowiring all over the place instead of instead of using constructor injection)

You can use whichever.

> anyone who uses any other framework is just stubborn and wrong.

Not at all. Spring Boot is just a great solution, that's all. It's got strong support from a company, lots of documentation and first class support for testing. It also allows you to easily swap out different underlying technology, eg. you can switch from Jetty or Tomcat, Liquibase to Flyway.

It's a disservice to persuade businesses to use smaller projects that don't have a comparable level of support, or flexibility.

> It's a disservice to persuade businesses to use smaller projects that don't have a comparable level of support, or flexibility.

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.

> we'd be doing ourt clients a great disservice to sell them on a microframework with our homespun implementations of security, transactions etc.

One of the benefits of Spring Boot was that Pivotal test and ensure all the components work together, so you can upgrade safely. It made keeping things up-to-date much easier.

There's no business value in trying to knit it all together yourself, if you can pass the work onto somebody else who is paid to do it.

> @SpringBootTest

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.

> 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 read the documentation to find out what every annotation does.

https://docs.spring.io/spring-boot/docs/current/reference/ht...

There are several different annotations that you can use to test each particular "slice" of your application, ranging from a fully embedded server, to just testing the controller layer without the embedded server, to just testing the data layer without controllers or servers.

What do you recommend instead?

A good first framework to wane off Spring is DropWizard. But there are countless others and they all do more or less the same thing, except much better, and with far less complexity, than Spring.