How to get a production ready Java application off the ground in the shortest time possible?

I’m not a morning person, so sometimes it takes a while for the “all systems are go” cue to kick in. This used to be true for Java applications until not too long ago, but unlike the invention of the snooze function on the alarm clock, the solution we’re going to discuss here actually makes much better sense. With modern open source frameworks like Dropwizard, Spring Boot, Groovy’s Grails and Scala’s Play! you’re able to build a production ready application from scratch in a matter of minutes. Even if you’re not a morning person. And even if you’re not fond of wizard hats. In this post we’ll discuss the similarities and differences of the lightweight Java based frameworks with Dropwizard and Spring Boot.

The Trade-off: Freedom of choice vs. The need for speed

Either framework you go with, you’re sacrificing some freedom of choice since both Dropwizard and Spring boot are highly opinionated and strongly believe in convention over configuration. How strong? You’ll discover just that in a side by side comparison we’ve done, examining the different flavors of 3rd party libraries that each of them adds to the mix. Most if not all core features a production grade application requires come out of the box or available as integrations.

The upside of this sacrifice is speed, although it’s fun at times to fiddle around with new libraries and customize your own perfect environment. When you need to get something quickly off the ground and start rolling, you’re better off delegating those decisions and getting rid of the complexity that comes with it. It’s not exactly a blue pill vs. red pill scenario: Further down the road when you’re up and running, you will most likely be able to customize and tweak it if needed. Now just direct your favorite build tool, be it Gradle or Maven, to Dropwizard & Spring Boot and you’re good to go.

Let’s dig in and discover which aspects of each framework will leave you locked-in and where you can be more flexible.

Spoiler alert: We faced a similar dilemma here at OverOps and decided to go with Dropwizard for an on-premise flavor of OverOps for enterprises. But what once could be seen as the default (and only) choice with Dropwizard, led us to break some prejudice we had with Spring boot and exhausting XML configurations.

Dropwizard vs. Spring Boot: Who’s got your backend?

A production grade application relies on many components and each framework has made its choices for us. All the weapons of choice to get a RESTful web application off the ground are laid down right here in this table with Dropwizard in the left corner with a wizard hat and Spring Boot in the right corner with the green shorts. The core out-of-the-box libraries and add-ons are separated by color with Spring’s internal dependencies marked in white.

Dropwizard vs. Spring Boot.

Dropwizard vs. Spring boot: 3rd party libraries

Ok, so now that we have a better view of the land, let’s see what this actually tells us. I’d also recommend taking a closer look at each of the frameworks, since everything is open-source and available for your viewing pleasure right on GitHub: Here are the Dropwizard source files, and here’s Spring Boot.

Spring Dependencies

Like it says on the tin, Spring Boot is focused on Spring applications. So if you’d like to get into the Spring ecosystem or already familiar with it and need to set up a quick application, this would probably be the way to go. The REST support, and DevOps features which we’ll talk about soon like metrics and health checks are based on Spring Framework’s core while DropWizard puts its REST support with Jersey. It’s pretty much the only aspect where Spring Boot leaves you locked-in, although it’s more flexible on other fronts (EDIT: JAX-RS support was added to Spring on v1.2, and can also be used with Jersey. Thanks Pieter!)

HTTP Server

Here we can see just how Spring Boot can be more flexible. Dropwizard takes the convention over configuration approach a bit more extreme than Spring Boot and is completely based on Jetty, while Spring Boot takes the embeddable version of Tomcat by default but leaves you a way out if preferer Jetty or even RedHat’s Undertow.


This is another example of the same convention over configuration issue, Dropwizard switched from log4j to Logback in v0.4. I’m guessing that with log4j2’s recent GA release, this might be subject to change (EDIT: Looks like that’s not the case, check out the comments section). On Spring Boot’s front, we need to make a choice between Logback, log4j and log4j2 if we require logging. By the way, if you’re using Logback, you can check out this benchmark we ran to compare the performance of different logging methods.

Find the Crap in Your Java App

Show me how >>


Dependency Injection

A main difference between both frameworks is dependency injection support. As some of you know, Spring’s core comes with it’s built in dependency injection support while with Dropwizard this doesn’t come out of the box and you’ll have to choose one of the community integrations that support it. A popular choice would be going with Google’s Guice, and using one of the community led integrations.

Testing – Fest vs. Hamcrest

Both frameworks have a special module for testing, dropwizard-testing and spring-boot-starter-test, including JUnit and Mockito dependencies. Spring Boot naturally uses Spring Test as well and the main difference here comes in the shape of matcher objects, checking if different objects match the same pattern. Dropwizard favors FEST matchers (which are no longer developed) (EDIT: moved to AssertJ in the latest 0.8 version) and Spring Boot goes with Hamcrest.

Debugging in Production

Unlike built in solutions for testing during the development stage, when your application is deployed in production there’s no guaranty that everything will go as planned. With OverOps in the mix, you’re able to know which errors pose the highest risk, prioritize them, and receive actionable information on how to fix them. If you want to level up your environment, you should definitely give it a go to see when and why code breaks in production.

No Dev Without Ops

To earn the title of a production grade application, each framework’s core features include support for metrics, health checks and tasks. In a nutshell, metrics allow you to keep track of stats like memory usage and timing of how long does it take to execute areas in your code. Health checks are a way of testing on the go and answering questions like, is this socket still open? Or is the database connection alive? And with tasks support you can schedule maintenance operations or periodic tasks.

The Dropwizard metrics library gained some popularity on it’s own and you can add it to any project, or even use it with Spring Boot’s metrics, to gain insight into what your code does in production. One cool feature is reporting to services like Graphite or Ganglia and some 20+ available integrations. Health checks also come with Dropwizard metrics and tasks are implemented as part of the framework. On the Spring Boot front, the framework uses Spring’s core features to support its Ops angle.

A note on going container-less

The key driver that enabled the creation of Dropwizard, followed by Spring Boot a few years later, are container-less Java HTTP servers. Unlike a standalone container, you can simply add an HTTP server like any other library dependency in your app. Straightforward, easy to update, and you don’t have to deal with any WAR files whatsoever. XML configurations are kept to a minimum. As to the deployment end of the story, both Dropwizard and Spring Boot make use of fat JARs to pack all JARs and their dependencies in one file, making it easier to deploy using a quick one-liner.

Community and Release Cycle

Dropwizard was initially released by Coda Hale in late 2011 back in his days at Yammer. Since then it passed some 20 versions, and currently stands on 0.8, enjoying great community support as the go-to guide for modern Java applications. On the downside, new releases are slowing down, after they used to come out every couple of months. In the latest 0.8 version we mostly see 3rd party version updates and minor fixes. Dropwizard currently supports Java 7 and above, to use it on Java 8 you can check out this partial update to enjoy some of its benefits and new features (or if you just don’t like joda-time for some reason).

(EDIT: A comprehensive list of Dropwizard modules is available right here).

Today you can see mostly commits from Jochen Schalanda (EDIT: and the 0.8 team) with over 160 individual contributors and tens of community supported integrations, like dropwizard-extra from Datasift. Of the available Dropwizard integrations, Spring support is also included. One more thing you should definitely check out is the official user group right here.

With Pivotal backed Spring Boot joining the game with a 1.0 in 2014, there are over 40 official integration (Starter POMs) to pretty much any 3rd party library you can think of. This includes anything from logging to social API integrations. One new Spring Boot project worth mentioning here is JHipster, a Yeoman generator for Spring Boot and Angular.

On the bottom line you could say that Dropwizard has a larger community around it and Spring Boot enjoys better official and structured support, together with Spring’s existing user base.


1. If you’re looking to get into the Spring ecosystem, then choosing Spring Boot is probably a no brainer. More than a way to bootstrap a RESTful Java application, it also acts as a gateway to Spring with integrations to tens of services. Maybe the real question here is whether you should start looking / go back into Spring? Which could be a whole other subject to discuss. Otherwise, Dropwizard would suit your needs best.

2. A second issue here is how dependent are you on dependency injection? If Guice is your choice then going Dropwizard and using one of the community integrations would be an easy fix rather than doing the Spring way of dependency injection.

3. And last but not least, taking a look at the side-by-side comparison, which framework makes the choices that you would take if you were to build an application from scratch yourself? Keep in mind the default picks since spending even more time configuring this bootstrap kind of betrays its cause.

I hope you’ve found this comparison useful and I’d be happy to hear your comments about it and the factors that made you choose one over the other.

This post is now in Spanish.

OverOps shows you when and why your code breaks in production. It detects caught and uncaught exceptions, HTTP and log errors, and gives you the code and variable state when they happened. Get actionable information, solve complex bugs in minutes. Installs in 5-min. Built for production.

Further reading:

Bug line

5 Error Tracking Tools Java Developers Should Know

Some kind of monster @ OverOps, GDG Haifa lead.
  • Tatu Saloranta

    Not that I have any official knowledge, but on “maybe log4j will be used now that log4j2 is going GA”, I think that is highly unlikely.
    Why fix something that ain’t broken: logback/slf4j is a very solid and nicely working framework, and while log4j2 is probably fine as well, there would have to be something really great to warrant a potentially intrusive change like that.

    • Alex Zhitnitsky

      Thanks Tatu! Right, Jochen seems to agree:, I’ll add a correction. The case for log4j2 is mainly for introducing async logging and the significant performance boost that comes with it, depending on how much is logging a bottleneck for your application.

  • Pieter_H

    Might want to correct that table, you can use JAX-RS with Boot see:

    • Alex Zhitnitsky

      Thanks Pieter! I’ll correct it

      • Dinesh R

        You can also use dropwizard metrics with Spring Boot, granted it is not out of the box.

  • jschalanda

    Thanks for the nice comparison of Dropwizard and Spring Boot!

    The releases of Dropwizard have slowed down a little bit but we (the maintainers of the project) plan to release Dropwizard 0.8.0 in the first half of March, 2015 and it currently looks as if we’d actually be able to pull that off. 😉

    Re: logging, as Tatu already wrote in his comment, it’s rather unlikely that we replace Logback with log4j 2 (also see #686) unless there’s either a massive advantage in using log4j 2 over Logback or Logback stops being maintained.

    Re: testing, while FEST assertions aren’t maintained anymore, we’ve moved to the successor project AssertJ in Dropwizard 0.8.0 (see #493).

    Re: community, there are lots of people who have contributed to Dropwizard in one way or the other. The reason you see the Yoshi avatar a lot is simply because I push the “Merge” button on pull requests quite often.

    By the way, a comprehensive list of addons for Dropwizard can be found at

    • Alex Zhitnitsky

      Hi Jochen, thanks for the comments! It clears up a few issues. I’ve added some comments in the post itself. How about the roadmap beyond 0.8? Any thoughts on a 1.0 version or moving to Java 8?

      • jschalanda

        There is currently no roadmap beyond Dropwizard 0.8.x. We’ll see after the release of Dropwizard 0.8.0 which features are most wished for in the community and which ideas are worth pursuing.

  • Pieter_H

    Great article! Boot and DropWizard are both great pieces of software.

    Dislaimer I work for Pivotal.

    when you say that DW has a bigger community, do you mean a user
    community or committer community? No offense to DW, but I have a hard
    time believing they have a bigger user community — Looking at public
    metrics like # of SO questions tagged it’s clear boot is >= 4x the
    size. DW has a few more stars in GH, but boot has more forks. Also,
    Boot was created much more recently so keep that in mind.

    • jschalanda

      The support for Dropwizard is mainly done on the mailing list. Spring is using Stack Overflow as its official support channel (also endorsed on, so it’s not really surprising that there are a lot of questions about Spring Boot on SO. 😉

      • Pieter_H

        Good to know thanks, yeah that seemed odd since I know DW has been around longer.

        When I compare mail list threads to SO questions it’s a little more like I expected – DW 1284 mail threads, SB about 2202 SO questions tagged, but sadly I don’t have time to filter out any DW emails like announcements etc that don’t originate from the community, and therefore likely aren’t an indicator of community usage. This seems to roughly correlate with Google Trends [1], indicating somewhere between 2x – 4x the user base. [1]

        Given this, I am going to assume the author was referring to committer / contributor community size and not user base.

    • Alex Zhitnitsky

      Hi Pieter, thanks for the comments and the Pivotal point of view! As to the community size, it’s not exact science but the main thing that captured my attention more than the GitHub figures and platforms for Q&A were the community endorsed integrations (and a hint of a subjective feeling from conversations I had). As to the user base, I see what you mean, given that Spring Boot has the backing of an existing Spring community.

    • Lubos Krnac

      I think Google trends is also metric that can be taken into account when talking about community size:

      • Pieter_H

        yes, I mentioned that below in my comment.

      • richmidwinter

        That suggests spring boot appeared in 2007. And possibly that users of it need to Google for help more?!

  • Yun Zhi Lin

    Awesome article. We are currently using Dropwizard for greenfield Microservices and SpringBoot for breaking down existing monolith Spring app. It’s good to see a side by side comparison.

    Re: DW guice injection, dropizard-guice also supports swapping in custom injectors such as NetFlix’s Governator. As of DW 0.8, SquareSpace’s jersey2-guice is incorporated for Jersey2 integration.

    • Pieter_H

      make sure to check out the new spring cloud projects – they wrap several different NetFlixOSS projects, and add significant capability to boot, specifically for microservices. Boot has some pretty sweet autobinding to Cloud Foundry services as well. All on top of the same DI mechanism from the folks that invented the concept…

    • Alex Zhitnitsky

      Thanks for the comment! Cool news for DW 0.8

  • cash1981

    Thanks! Great post

  • Samatha

    Thanks for the comparison, putting them alongside in a table.

  • Mohit Keswani

    The issue i found out with dropwizard is that they are very tightly integrated with Template driven Views and don’t support JSP

  • lucian enache

    I find the comparison between Jersey and JAX-RX a little bit ambiguous, since you are comparing an implementation with a specification which is not exactly the same. Correct me if I’ve missed anythings

  • Kabram

    The one downfall of DropWizard is their wrapping of well known specs with their proprietary api. Example: I know how to configure logback for my logging needs. However, with DropWizard, I can’t simply drop in my logback config file. I have to write it using their yaml specification. This is unnecessary cognitive overhead. They are reinventing things that don’t need reinvention.

  • Rémi Alvergnat

    About dependency injection, since 0.8 dropwizard is now shipped with HK2 which is the reference implementation for JSR-330. @see

    • Steve Millidge

      Which interestingly is the core of Payara and GlassFish.

  • Steve Millidge

    Have you thought of comparing Payara Micro which does something similar without messing with Maven? You just drop in a Java EE 7 Web Profile war file.

  • Pieter_H

    I found this recently, and while it favors Spring Boot it’s not written by an employee, just an enthusiast

  • taruni nandu

    Thanks for the content……
    Information given by you is useful for our company IT Hub Online Training top in giving Spring Online Training service.