For me dropwizard looks like what you'd get from a room if experienced Java guys picking the best of breed to do one thing and one thing well.

Spring boot feels like it was from a room full of people where there's a guy in the corner with a form of tourettes that makes him keep yelling "Spring! Take the Spring option!"

It just isn't always the best option and sure, you can often switch out for something else but that defeats the point of an opinionated collection of the best available choices.

If you think Spring could make better bundling choices, tell them. They are very open to feedback.

And if they don't qualify as "experienced Java guys" then I don't know who can, short of Gosling.

Agreed. Kotlin + Dropwizard is an interesting approach. How well do Kotlin and Jersey play together in your experience?

Wonderfully, no complaints so far.

You should add the Jackson Kotlin module so you can pass Kotlin data objects around: https://github.com/FasterXML/jackson-module-kotlin

This combination has made me as productive as I've ever been.

One big drawback of Dropwizard (at least for us) was that it was very problematic to deploy it as a war in a tomcat environment. There is wizard-in-a-box but there were a lot of issues with that as well.

Yeah, that's definitely a square peg + round hole problem. Dropwizard is intended to be deployed as a "Fat Jar" and does not need tomcat/tomee.

This is nice because it makes it easier to treat your servers like disposable cattle when (almost) all of your configuration and dependencies live in your easily deployed Jar.

If you're deploying a dropwizard app as a war in tomcat you're doing something a bit odd.

True but sadly project specs sometimes change in odd ways.

Well, if you're doing microservices you're usually nullifying most of the benefits of this kind of architecture if you're just deploying them on war files on a single application container.