DropWizard is mostly meant for creating a set of conventions to production-ready applications with operations-friendly things like instrumentation hooks. Jodd i

DropWizard is mostly meant for creating a set of conventions to production-ready applications with operations-friendly things like instrumentation hooks. Jodd is oriented more around simpler libraries for doing what people have oftentimes used heavyweight frameworks for (not in terms of performance though necessarily but in terms of mental efforts and scaffolding required to get a MVP out the door). You could use both frameworks together because they have almost orthogonal concerns and both being minimal don't step on each other's toes. Jodd in itself could work for not needing an app container by using something like Winstone (Jenkins is built with it) for deployment models closer to systems like node.js or Flask and Sinatra that emphasize minimal scaffolding to make it easier to horizontally scale a system by just deploying more dumb nodes. I've seen Jodd used in production systems and just never seen a stacktrace fail to that point so far. I've only ever seen application code fail in itself or fail due to a side effect or misunderstanding of the underlying libraries. I've seen FAR more bugs due to the ugliness of the old Java dateutil libraries than Jodatime, for example, but would we argue Jodatime is more or less mature? Maybe I didn't answer your question but I'd say if you're looking for super stable libraries I'd argue on a time basis alone to just use core Java then. The very point of minimalism from a reliability perspective is to reduce points of failure in code with simply less parts. And really, with the number of deployment headaches I've had resolving random classes across an app container, I could take one less transient dependency in my project.