With Spark[0] (not to be confused with Apache Spark ...), you can get a Sinatra-like routing library on top of Jetty (while you still can deploy the webapp in a more heavyweight container if you need to).
I think Spark is in spirit much like Dropwizard, but a bit more lightweight.
I think that Spark comes at the cost of customisability - 2-way SSL is a chore, you have to parse your own message bodies, you don't get straightforward logging out of the box - there's a base set of features and functionality that I couldn't find in Spark.
The thing that impressed me about Dropwizard is that you can get in perhaps 50 lines of boilerplate a really solid core behind an application - with Spark you can do that in perhaps 20, but you are somewhat limited beyond that.
This was because that package depends on a different version of jersey-jackson or whatever, which was discovered by classpath scanning, and so because Eclipse doesn't keep a separate test classpath, we'd be discovering a new MessageBodyWriter which Jersey would be using to override the Dropwizard supplied MessageBodyWriter, which would not have the appropriate Jackson modules.
It was a mess.
It is a littlebit sad, that there are no javac warnings enabled by default that at least check known classes for conflicts in the classpath. An IDE should do that by default, too.
Where does bytecode manipulation or code generation happen in Dropwizard? Reflection for sure, but not any more so than any major web framework in a dynamically typed language.
Maybe you're referring to the SQL library they suggest (which I've admittedly never used heavily). But I don't see how you can have a SQL library without generating SQL.
For reference, what types of languages/frameworks do you like to work with?
I've also had good luck with Spring Boot, but it's a little magical for my tastes - I vastly prefer Guice for Java DI - just straightforward and predictable (that's just my subjective take though).
Dropwizard is a good bundling of stacks, but I don't think it'd match my personal preferences.
I will say that doing rest-style service work in modern Java frameworks is actually not too bad these days. Java 8 makes it even nicer.
IntelliJ (Jetbrains are the leaders behind Kotlin) has first class support for the language. Gradle will have support for Kotlin as it's DSL in it's next major iteration.
Despite some very loud people on the internet, it seems to have close to zero adoption, and JetBrains making big promises and then failing to deliver anything is not really helping them.