[AnyTimeTraveler]

I've used Javalin as well and now I understand why it all looked pretty familiar, but I kept thinking "Javalin did x better". I can recommend Javalin as well! Having used the Spring Framework, this is a delight in comparison. Especially the setup is infinitely easier. (I know Spring Boot exists, but that's just a preselected pile of software that I have to understand)

[usrusr]

The spring boot dread: which of the defaults are a terrible idea to replace, and which of the defaults are a terrible idea to keep?

I do wonder, when looking at the examples, if it might be nice to have a spark/javalin-like that depends on okhttp and reuses everything that appears on both sides of the connection. okhttpd if you like, even if perhaps still best built on top of jetty, like spark/javalin. Might have some skill reuse benefits, but might also cause some unintended shortcut accidents when the type system can't tell upstream from downstream objects.

[rjst01]

A big advantage that Javalin and some of the other micro-frameworks have over Spring Boot have is that by picking Spring boot, you are also implicitly picking Spring's custom Java classloader and packaging, and Maven or Gradle as a build tool.

The tooling for building Spring Boot apps from other build systems like Bazel has problems, and while you can forego it and build your Spring Boot apps with Bazel's java_binary targets, you really don't want to.

Javalin by contrast is a plain boring Java dependency and you can pull it into any Java app with ease.

I do miss the better support for OpenAPI in Spring Boot though - Javalin's support is still missing a lot of functionality, but it is being very actively developed.