# Dropwizard: Jetty, Jersey and Jackson wired into one deployable JAR

> An opinionated Java framework that picks a stack for you instead of letting you assemble one, with metrics, migrations and validation included rather than left as your problem.

**dropwizard/dropwizard** — A damn simple library for building production-ready RESTful web services.

- Repository: https://github.com/dropwizard/dropwizard
- Website: https://www.dropwizard.io
- Stars: 8,583 · Forks: 3,401
- Language: Java
- License: Apache-2.0
- Published: 2026-10-06 · Updated: 2026-10-06 · Language: en
- Canonical page: https://hysenlabs.com/projects/dropwizard-dropwizard

## A stack decision made on your behalf

The README states the pitch in one line and it is worth taking literally: Dropwizard is described as a sneaky way of making fast Java web applications, and as a bit of opinionated glue code that combines libraries which historically have not been great together. The word opinionated is the whole argument. Most Java stacks give you a menu and leave the decisions to you. This one picks.

The picks are named in the README as a bulleted list, each with a deliberately informal label: Jetty for HTTP serving, Jersey for REST modelling, Jackson for JSON parsing and generation, Logback for logging, Hibernate Validator for validation, Metrics for understanding what the application is doing in production, JDBI and Hibernate for the database layer, and Liquibase for migrations. Eight libraries, chosen, with a stated reason for each.

What you get from that list is a real constraint. If your team needs gRPC, or prefers jOOQ over Hibernate, or wants Kotlin coroutines in the routing layer, you are now working against the framework rather than with it. That is the trade Dropwizard asks you to make explicitly, and it is why the project attracts teams who have already made these choices and want them enforced.

## What the module tree reveals about how much is already built

The repository root is the clearest description of the framework's scope, because Dropwizard ships far more than the eight libraries in the README list. Each entry is a published artifact:

```bash
dropwizard-core/
dropwizard-jersey/
dropwizard-jetty/
dropwizard-jdbi3/
dropwizard-metrics/
dropwizard-validation/
```

The list continues into areas that a hand-rolled Java service usually assembles separately: `dropwizard-migrations` for Liquibase, `dropwizard-health` for health checks, `dropwizard-request-logging`, `dropwizard-json-logging`, `dropwizard-auth`, `dropwizard-client`, `dropwizard-forms`, `dropwizard-assets`, `dropwizard-views` with separate `dropwizard-views-freemarker` and `dropwizard-views-mustache` modules, `dropwizard-lifecycle`, `dropwizard-hibernate`, `dropwizard-http2` and `dropwizard-unix-socket`.

Three of those deserve comment. `dropwizard-bom` and `dropwizard-dependencies` exist so that version alignment across all of those modules is a single decision rather than a negotiation, which is the failure mode of any hand-assembled Java stack. `dropwizard-testing` and `dropwizard-e2e` exist because the project tests its own wiring. And `dropwizard-benchmarks` is unusual to see in a root listing: the framework measures itself.

## Production concerns arrive as modules, not as your code

The most useful thing about Dropwizard is that the operational concerns arrive pre-wired. Metrics is in the base list in the README, described as the way to work out what your application is doing in production, and `dropwizard-metrics` plus `dropwizard-metrics-graphite` show it is a first-class module with its own Graphite reporter.

Structured logging is handled by `dropwizard-json-logging` and `dropwizard-logging`, request logging by `dropwizard-request-logging`, and configuration by `dropwizard-configuration`, which is the module that turns a YAML file into typed configuration. Migrations ship as `dropwizard-migrations`, health checks as `dropwizard-health`.

Two entries stand out as things most teams end up writing themselves. `dropwizard-auth` covers authentication and authorization, and `dropwizard-client` covers outbound HTTP, which in a Java service is usually the second largest source of boilerplate after persistence. The presence of `dropwizard-http2` and `dropwizard-unix-socket` shows the project keeps pace with deployment realities like sidecar sockets rather than assuming every service sits behind a port.

## Two maintained major versions and a dependency-bump cadence

The releases are the clearest signal about where this project is in its life. Version 5.0.2, published 2026-05-31, is a maintenance release on the 5.0.x line: Jetty to 12.1.6, commons-codec to 1.21.0, mysql-connector-j to 9.6.0, Logback to 1.5.27, all attributed to Renovate.

Version 5.0.1, published 2026-01-28, does the same for Guava, Bouncy Castle, AssertJ and NullAway, and adds one human change: an upgrade note listing Jackson 2.20.x. Version 4.0.17, published the same day, runs in parallel on the 4.0.x line with Logback throttling appender and metrics-bom bumps and three small fixes by the maintainer, including a documentation fix for an incorrect format string in `archivedLogFilenamePattern`.

Reading these together says two useful things. First, the project is alive: the last push was on 2026-09-20, four months after the most recent release, and the repository is not archived. Second, it is in maintenance mode rather than feature mode. Almost every entry in these three releases is a dependency bump, which is what a mature framework should look like, but it also means new capability arrives slowly and 4.0.x users are not being walked forward quickly.

## Build and contributor infrastructure

The root contains the scaffolding that tells you how the project itself is run. There is `mvnw` and `mvnw.cmd`, so the Maven wrapper is committed and a contributor needs no local Maven install. `.mvn/` holds the wrapper configuration. Beyond that there is `pom.xml`, `dropwizard-parent/` for shared build settings, and `jreleaser.yml` for release automation.

Continuous integration appears in more than one place, which suggests it migrated rather than started from scratch. There is a `.circleci/` directory, an `appveyor.yml` for Windows, a Gitpod badge in the README that opens the project in a browser-based development environment, and a `.devcontainer/` directory. The README badge points at a workflow named Java CI.

Quality gates are wired into the build rather than left to review. The README carries a SonarCloud quality gate badge, a CodeClimate maintainability badge, and a reproducible builds badge pointing at the JVM Repo Rebuild service, which verifies that published artifacts can be rebuilt from source and produce identical bits. For a framework whose entire value proposition is that it pins versions for you, having those pins independently verified is more than cosmetic. There is a `docs/` directory, a `.readthedocs.yaml` for the documentation site, and a `RELEASES.md` file, with the live documentation at dropwizard.io.

## Where the README stops and the docs begin

The README is short by design and it reads like a project charter rather than a manual. It gives you the pitch, the library list, a link to dropwizard.io, and then two administrative sections: one for contributors pointing at `CONTRIBUTING.md`, and one for bug reports.

That reporting section is more revealing than it looks. It asks you to check existing issues first, to state the Dropwizard version you are on, to describe the expected outcome, to explain how someone else could reproduce the problem, to paste logs inside triple backticks, and to write a unit test demonstrating the issue. That last request is unusual in a README and it tells you the project expects test-backed bug reports rather than anecdotes.

Everything else lives on the documentation site, which the README links in two places and which is built from the `docs/` directory. If you are evaluating Dropwizard, the configuration model, the migrations guide, the authentication recipes and the upgrade notes are all there and none of them are in the repository README. The honest summary is that the README tells you why the project exists, and dropwizard.io tells you how to use it.

## Conclusion

Dropwizard is at its best when you agree with its choices. The value is not that Jetty or Jackson are good, it is that you did not have to pick them, wire them, or discover halfway through a project that your team needed something else. The module tree shows how much of the wiring is already solved: metrics, request logging, migrations, health checks, form handling, assets and free marker or mustache views all ship as modules rather than as things you assemble. The recent releases are almost entirely dependency bumps by Renovate, which tells you maintenance is real but slow-moving, and that two major lines, 4.0.x and 5.0.x, are still receiving patches. Start from dropwizard.io's stable documentation rather than the README, since the README is a project charter and not a manual.

## FAQ

### What is DropWizard used for?

It is used to build RESTful Java web services as a single deployable artifact. The README describes it as opinionated glue code that combines Jetty, Jersey, Jackson, Logback, Hibernate Validator, Metrics, JDBI, Hibernate and Liquibase into a working service rather than leaving you to choose and wire them.

### Which is better, Spring Boot or DropWizard?

They make opposite bets. Spring Boot lets you assemble a stack from starters and add dependencies as you need them, while Dropwizard commits to a fixed set of libraries and wires them for you, so you get metrics, logging, migrations and health checks without configuring them. The choice comes down to whether you want to keep making stack decisions or would rather adopt someone else's.

### Does Dropwizard include database migrations and metrics?

Yes. The README lists Liquibase for migrations and Metrics for understanding what the application is doing in production, and the repository ships dropwizard-migrations, dropwizard-metrics and dropwizard-metrics-graphite as separate modules alongside dropwizard-jdbi3 and dropwizard-hibernate.

## Sources

- [dropwizard/dropwizard on GitHub](https://github.com/dropwizard/dropwizard)
- [License: Apache-2.0](https://github.com/dropwizard/dropwizard/blob/release/5.0.x/LICENSE)
- [Project website](https://www.dropwizard.io)
- [README](https://github.com/dropwizard/dropwizard/blob/release/5.0.x/README.md)
- [Releases](https://github.com/dropwizard/dropwizard/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/dropwizard-dropwizard