
Dropwizard 0.8.0: Java framework for ops-friendly, high-performance web services - koevet
http://dropwizard.io
======
koevet
I'm the OP of this post, which was changed to show Dropwizard home page. My
initial post was about the release notes for Dropwizard 0.8
([https://dropwizard.github.io/dropwizard/0.8.0/docs/about/rel...](https://dropwizard.github.io/dropwizard/0.8.0/docs/about/release-
notes.html#v0-8-0-mar-5-2015))

They are quite significant. IMO, the most relevant one is the move to Jersey 2
(the Jersey framework is THE JAX-RS implementation for building REST services)
which supports Server side async requests
([https://jersey.java.net/nonav/documentation/2.0/async.html#d...](https://jersey.java.net/nonav/documentation/2.0/async.html#d0e6914))
and took quite a lot of work to be implemented in Dropwizard.

Finally, here is a link to third-party modules for DW:
[http://modules.dropwizard.io/](http://modules.dropwizard.io/)

~~~
threeseed
They really should have written those async examples with Java 8. Definitely
simplifies it:

[http://www.codejava.net/java-core/the-java-
language/java-8-l...](http://www.codejava.net/java-core/the-java-
language/java-8-lambda-runnable-example)

~~~
real_joschi
I totally agree but Jersey 2.x and Dropwizard still support Java 7, so the
examples should also work with Java 7.

------
dawidloubser
One of the strenghts of the Java platform is the separation of vendor-neutral
standards (e.g. JAX-RS, and all the REST concepts, and annotations, it
provides) and particular implementations (e.g. Jersey).

Java EE is a collection of such standards, providing enormous capability while
not tying you to a particular app server - I'm busy with a rather painless
JBoss -> Glassfish migration as we speak.

Secondly, Java has ample platforms that allow for the developer-driven
assembly of various cool libraries into a "platform" \- for example, OSGi.

It concerns me that this library absolutely ignores these two most valuable
concepts in the Java world.

If you want high-performance web services with much more powerful backing
technologies (EJB, JPA, JMS...) without locking into a particular haphazard
collection of libraries, just write and deploy a JAX-RS module into your free,
lightweight app server of choice (Wildfly, Glassfish, etc).

The Java ecosystem is much more mature than the Node.js-based "arbitrary
assembly of X cool libraries" that this little project is emulating, and I
would encourage people to put that same effort into understanding Java EE,
which over the past 5 years has become a lean, lightweight platform indeed -
but one with real horsepower for serious systems when you need it.

Not denouncing the greatness of the libraries that have been combined here,
I'd steer clear of this project - you're missing out on what is really
possible.

~~~
cssmoo
You're right but wrong. That's all OK in theory but not in reality having
migrated various Java EE gubbins on a project. It's a rat's nest of supposed
standards and interop that doesn't amount to much at the end of the day
because there's still coupling to infrastructure and configuration at every
level. On top of that there's edge cases that the APIs and standards don't
consider as they're all pretty leaky.

Dropfish is a cohesive "opinion in a box" that just works without having to do
a Java EE iteration zero which is hours of eye-stabbing pain. Someone did all
the hard work of swapping components out until they found something that
wasn't horrible and stuck them all together.

The Java EE ecosystem is mature, you're right but it's not pleasant, is
inflexible despite its modularity and doesn't live up to it's promoted
abilities.

Saying that I've used both in production, but would rather can both of them
and use something like flask and python with SQLAlchemy just for the fact I
don't have to deal with massive heavyweight environments and it's possible for
a human to understand it all in a lifetime.

Also, 500 level deeps stacks in Java+OSGI projects make me cry. Trac has a
better composition and component model!

~~~
dawidloubser
I've had some terrible experiences with migrating, and maintaining, Java EE
apps before. But every single one of those were caused by how the teams built
the system, and not by Java EE itself.

The added complexity, and choices, imposed by Java EE require a degree of
understanding, maturity, and ability to abstractly design that is beyond the
average programmer that just quickly wants to hack together a couple of REST
services.

I'm not trying to paint successful Java EE developers as some sort of elite
here, but there is no doubt that people with a solid understanding can, and
have, built long-lasting systems of beauty with it, whereas the average un-
informed team, having managed to soundly lock themselves into awful pre-2005
app servers, have created conterted messes of Java code beyond belief.

Both Java EE, and OSGi, are soundly beautiful in their own ways, but both have
suffered from some awful implementations and libraries that have caused a lot
of pain.

For the past 5 years, my experiences with Java EE has been everything but
"heavyweight". I consider it a rapid application development environment.
Especially now that nobody does any server-side view frameworks anymore (it's
all ECMAScript in the browser).

In this world, I challenge any environment to put more horsepower behind your
REST services, for less effort.

~~~
tokenizerrr
> For the past 5 years, my experiences with Java EE has been everything but
> "heavyweight". I consider it a rapid application development environment.
> Especially now that nobody does any server-side view frameworks anymore
> (it's all ECMAScript in the browser).

Do you have any recommended reading for that? Every time I try to get started
with Java EE I am plagued with outdated material and pages upon pages of
boilerplate XML configuration.

~~~
nbw-hn
Check out the JavaEE tutorial from Oracle
[http://docs.oracle.com/javaee/7/tutorial/](http://docs.oracle.com/javaee/7/tutorial/)
and the 1st Cup
[https://docs.oracle.com/javaee/7/firstcup/index.html](https://docs.oracle.com/javaee/7/firstcup/index.html)

There's also an excellent GIT repo of JavaEE7 samples that is maintained by
RedHat here:

[https://github.com/javaee-samples/javaee7-samples](https://github.com/javaee-
samples/javaee7-samples)

------
threeseed
If you're missing Go-like channels, actors etc then check out Quasar with can
be integrated with Dropwizard using a library called Comsat.

It's pretty cool to take an existing Dropwizard app, change a couple of lines
and every request becomes a lightweight fiber:

[http://docs.paralleluniverse.co/comsat/](http://docs.paralleluniverse.co/comsat/)

[http://docs.paralleluniverse.co/quasar/](http://docs.paralleluniverse.co/quasar/)

~~~
crudbug
Is Quasar ready for production use?

~~~
pron
Yes (I'm the main author)

------
EtienneK
I love Dropwizard and I love the direction they've steered Java Web
Development in, but I prefer Spring Boot: [http://projects.spring.io/spring-
boot/](http://projects.spring.io/spring-boot/)

I find it much quicker to get started with, much better supported and better
tooling.

~~~
brown9-2
One thing that felt weird to me about Spring Boot when I looked at it a year
or so ago was the idea of enabling features based upon which libraries are on
the classpath.

Has that turned out to be useful in practice? Seems like a simple method for
unpleasant surprises.

~~~
switchbak
I've definitely been nabbed by unpleasant surprises while using it - when you
have lots of transitive dependencies you can get some surprisingly interesting
behaviour :)

That said, you can also be fairly granular about you configuration (instead of
the auto-config), so it's not that bad.

------
abalone
Love Dropwizard! Here's the notes on what's new in the March 5 release. Can
anyone summarize the best bits?

[http://dropwizard.github.io/dropwizard/0.8.0/docs/about/rele...](http://dropwizard.github.io/dropwizard/0.8.0/docs/about/release-
notes.html#v0-8-0-mar-5-2015)

~~~
Xorlev
The move to Jersey 2.

~~~
stuff4ben
I wouldn't necessarily call that a good thing. Jersey2 has been a PITA to get
working with one of our internal apps that used Spring. Looks like I'm not
alone in this either: [https://github.com/gwizard/gwizard#why-did-you-pick-
resteasy...](https://github.com/gwizard/gwizard#why-did-you-pick-resteasy-
over-jersey).

------
latchkey
If you're interested in a Guicier 'framework' inspired by Dropwizard, take a
look at GWizard...
[https://github.com/gwizard/gwizard](https://github.com/gwizard/gwizard)

~~~
e12e
Hm, looks like I can find examples of using kotlin with guice, and kotlin with
dropwizard, but no examples of kotlin with gwizard... After recently looking
at java8 and alternatives, I've tentatively come to the conclusion that I'm
rather happy to use kotlin for stuff that needs to be (almost) java (eg:
Android, or just mapping closely to java, eg: dropwizard?) -- and clojure for
everything where java feels too constrained (but where perhaps performance
isn't much of an issue). For myself, I don't see much use for scala -- it
feels too complex, and in many ways less powerful than clojure. Note that I
don't have any legacy java/jvm code, and so I probably just use ocaml or even
standard ml where others might reach for scala.

Perhaps kotlin doesn't make much sense wrt dropwizard -- it might make more
sense to just stick with java for dw, and use something different if one wants
something higher level?

Anyway, some related links I've come across googling a bit:

clojure+dropwizard (example, with leiningen):

[https://github.com/stevensurgnier/dropwizard-
clojure](https://github.com/stevensurgnier/dropwizard-clojure)

Experimental (old) repo for dropwizard+kotlin:

[https://github.com/arteam/kotlin-
dropwizard](https://github.com/arteam/kotlin-dropwizard)

Combining kotlin and guice:

[http://java.dzone.com/articles/kotlin-guice-
example](http://java.dzone.com/articles/kotlin-guice-example)

~~~
doomspork
I've been using Kotlin and Dropwizard together and I quite enjoy it. To
demonstrate Kotlin recently for a friend I used the Dropwizard Getting
Started: [https://github.com/doomspork/kotlin-
dropwizard](https://github.com/doomspork/kotlin-dropwizard)

My plan is to add more to it and eventually cover all the features of
Dropwizard.

------
Randgalt
FYI - I've written some bundles/extensions to DW 0.8.0 that support SOA.
[http://soabase.io](http://soabase.io) \- Service Discovery; Load Balancing
REST Client; Distributed, Scoped Dynamic Attributes; Jersey-based Admin APIs;
Administration Console; Configuration Utilities; Guice Integration

~~~
argc
This looks really cool, thanks for sharing!

------
paukiatwee
I built an open source personal budget app using DropWizard 0.7.0 awhile back
with AngularJS. If you guys have interest to see real world project using
DropWizard, check this out
[https://github.com/paukiatwee/budgetapp](https://github.com/paukiatwee/budgetapp)

Cant wait to upgrade to use v0.8.0 :)

------
labianchin
Also, saw this comparison of Dropwizard with Spring boot:
[http://blog.takipi.com/java-bootstrap-dropwizard-vs-
spring-b...](http://blog.takipi.com/java-bootstrap-dropwizard-vs-spring-boot/)
Interesting to understand the libs and flexibility each one have.

------
crudbug
Congratulations, one of the best frameworks in the JVM land.

~~~
pron
Absolutely. But it's more a curation of some excellent libraries than an
independent framework. At the top of the list are Jersey, the reference
implementation of the JAX-RS standard, and Jetty (DW's servlet container).
Metrics (by the same author as Dropwizard) deserves another honorable
mentions.

------
ww520
What is the option for rapid application development using Dropwizard? Is it
possible to refresh a web page and the code changes are automatically compiled
and deployed?

~~~
idunno246
most IDEs have support for this - you can change a method while debugging even
and itll reset the stack with your changes. Theres also pro tools like jrebel
that are supposed to solve it better than the built in stuff.

~~~
bni
As long as you dont change any method signatures, sure. I think its the JVM
that provides this as part of its remote debugging functionality.

If you change any signatures (should be most of the time) you need Jrebel.

------
jimbokun
Seems like Dropwizard makes it possible to follow the twelve factor app
approach in a Java application.

[http://12factor.net/](http://12factor.net/)

Especially the "Processes" factor.

"Execute the app as one or more stateless processes"

[http://12factor.net/processes](http://12factor.net/processes)

You need something like Jetty, running in the same process as the app (as
opposed to an application container like Tomcat) to make this approach work.

~~~
foolinaround
Is there a sample "pet shop" app?

------
stuff4ben
While I like the opinionated nature of Dropwizard, there's still a lot of
manual stuff you have to do to get things working. Wish it had some automation
built-in similar to Grails and JHipster
([http://jhipster.github.io/](http://jhipster.github.io/))

------
chaostheory
This vaguely reminds me of Play v1. It feels simple (err simpler) and not
overly complicated like a typical Spring based app. Of course, this may change
over time.

I really loved the Play v1.x framework minus the hard to debug part.

~~~
brown9-2
Why was it hard to debug?

~~~
chaostheory
It's been a while, but if I remember correctly Play v1.x's 'magic' depended on
Play v1 messing with Java bytecode. Well this in turn makes it harder to
debug. This is no longer an issue with Play v2, but the magic (and the fun)
are gone.

~~~
jlward4th
The reloading part of Play doesn't use bytecode manipulation, it simply
creates a new classloader with the newly compiled stuff and then uses the new
classloader on subsequent requests. There are other pieces of Play 1 & 2 that
do bytecode manipulation. In Play 2 this is pretty minimal when using Java /
EBean.

------
th3iedkid
we had used metrics library of theirs for some of our projects while
evaluating, quite a while back. It was worthwhile for minute scale testing and
was interesting to note that it had a few things worth abstracting from an
instrumentation framework standpoint.

It integrates with all common monitoring tools/frameworks and best part was
its JMX integration which seemed to be more lightweight compared to a few
other commercial ones we tried.

We then stopped instrumenting for other reasons.

~~~
real_joschi
> We then stopped instrumenting for other reasons.

Any reasons you want or are allowed to share?

------
smoyer
Dropwizard keeps getting heavier ... JavaEE keeps getting lighter. Dropwizard
has always been friendly to developers, JavaEE took a long time to "become
useable" (I was ready to give up on J2EE completely with release 1.4).

It would be interesting to compare the demo Dropwizard application with an
equivalent one written in JavaEE 7. Is anyone interested? I'd be willing to
run through both sides (I always learn something!).

~~~
koevet
I'm not sure why you assert that Dropwizard is getting heavier. The difference
between this release (0.8) and the previous one, is just about bumping up a
bunch of libraries' versions and the big move to Jersey 2.

DW is essentially a collection of libraries with sane defaults and some
plumbing, so I don't see how you can compare it to JEE. JEE may be lighter
these days, but it still requires a container to run - unless you use the
latest incarnation of the IBM JEE server, Liberty.

~~~
dawidloubser
Dropwizard also requires a container to run. Only difference is, they are
bundling a particular container (Jetty), as opposed to the model of deploying
into a container that you set up.

~~~
tedyoung
I think you're using the word "container" when perhaps "app server container"
is more meaningful. An app server container (like Tomcat, WebLogic, WebSphere,
etc.) typically provides services (database connectivity, persistence,
management, etc.) to the applications deployed into the app server container,
where the benefit is especially useful when multiple applications are deployed
in the same container (though in my experience, this is often where problems
occur and people end up deploying separate app servers per application).

Dropwizard is meant to run without an app server (aka containerless), and uses
the Jetty embedded web server (which is not an app server container) to
provide the HTTP communication.

------
Zombieball
I remember Dropwizard being a favourite amongst many folks at a previous job.
Decided to read the listed contributors to find some of their names:

Hats off to you Adam Jordens & Cameron Fieber :)

------
raz32dust
Is there anyone who has tried both rest.li as well as dropwizard? How is
dropwizard different? (I know only rest.li and have found it to be quite good
in what it does)

------
otterley
Why choose Metrics over Servo? Metrics lacks dimensions, which is a pretty
significant oversight, IMO.

~~~
rckenned
Metrics was created before Servo. Some folks at Netflix wanted to use Metrics
but ran into fundamental differences of opinion with us (Yammer) that we
weren't willing to yield on. So Netflix built Servo and Dropwizard kept going
with Metrics.

~~~
otterley
What weren't you willing to yield on? If it was that metrics should have
dimensions, Netflix has the stronger argument.

------
zooso
Love Dropwizard.

Development, testing, deploying, and monitoring the way it was supposed to be.

------
shaun234
Nice framework!!

------
dang
Url changed from [http://dropwizard.io/about/release-
notes.html#v0-8-0](http://dropwizard.io/about/release-notes.html#v0-8-0)
because this project doesn't appear to have been discussed on HN before.

~~~
Yhippa
[https://hn.algolia.com/?query=dropwizard&sort=byPopularity&p...](https://hn.algolia.com/?query=dropwizard&sort=byPopularity&prefix&page=0&dateRange=all&type=story)

~~~
dang
Oh, I didn't mean it had never been posted before. I meant that none of the
previous posts received significant attention or discussion. Sorry for not
being clear.

~~~
stock_toaster
Having heard of dropwizard many times before (isn't it pretty popular?), and
arriving post edit, I was left wondering why this was posted, until I read the
comments and found this subthread.

It would be nice if there was a section for admin comments right below the
link, where things like this could be mentioned instead of relying on comment-
thread popularity to bubble it up.

------
tapirl
all java frameworks suck. Hidden too much, concepts too much, config too much,
dependencies too much, memory consumed too much, development circle too long,
startup too slow.

that is why golang is born.

(I know this comment will be downvoted, but it is the reality, NEVER USE JAVA
TO DEVELOP YOUR WEBSITE!)

~~~
flaie
spring-boot is awesome, the configuration is simple, the development is
absolutely quick and easy and startup takes just 3 to 4 seconds on my mac.
Seriously you just don't know what you're talking about.

And for that matter I really appreciate Go and its simplicity.

~~~
tapirl
on your mac, 3-4 seconds? Then on a micro EC2 instance, it would be 10+
seconds. You visitors has gone before your page is loaded.

btw, there are very few big companies use spring. It is a over promoted
products.

btw2, do you know how to cache the jsp template render result? Which is so
easy in other languages.

~~~
flaie
Don't you know the difference between the startup of an application container
(which takes 3-4 seconds) and a page refresh which depends on what your
application is doing?

There are __a lot __of companies using Spring, at least in Europe I can 't
count them. I don't know on what planet you're living :)

~~~
tapirl
When your app is PaaS based, startup time (and memory usage) is very
important, for your instances will restart often.

Don't know if there are any big IT companies in Europe.

No only spring but also java is a over-promoted product. Before being acquired
by Orcale, Sun devoted much of its money to promote Java.

~~~
Twirrim
Java and spring are everywhere. I think you'd be (unpleasantly?) surprised
just how often you're using websites that are running on top of Java and you
just didn't know it.

~~~
tapirl
for examples pls. There are really some, but very few.

~~~
Twirrim
Okay, if you insist..

Amazon (significant amounts of the infrastructure run on Java, take a look at
their jobs board:
[http://www.amazon.com/gp/jobs/ref=j_sq_btn?jobSearchKeywords...](http://www.amazon.com/gp/jobs/ref=j_sq_btn?jobSearchKeywords=Java&category=*&location=*&x=0&y=0))

Google ([http://www.quora.com/Why-does-Google-prefer-the-Java-
stack-f...](http://www.quora.com/Why-does-Google-prefer-the-Java-stack-for-
its-products-instead-of-Python/answer/Robert-Love-1))

Twitter (They started out entirely Ruby, but converted pretty much their
entire stack to the JVM through use of Java and Scala, due to scaling issues
[http://www.wired.com/2013/09/the-second-coming-of-
java/](http://www.wired.com/2013/09/the-second-coming-of-java/))

LinkedIn ([https://engineering.linkedin.com/play/play-framework-
linkedi...](https://engineering.linkedin.com/play/play-framework-linkedin))

Yahoo

Facebook
([https://www.facebook.com/careers/department?dept=grad&req=a0...](https://www.facebook.com/careers/department?dept=grad&req=a0IA0000006cQPNMA2)
[https://www.facebook.com/careers/department?dept=grad&req=a0...](https://www.facebook.com/careers/department?dept=grad&req=a0IA000000G3E1tMAF))

Salesforce
([http://salesforce.careermount.com/candidate/job_search/quick...](http://salesforce.careermount.com/candidate/job_search/quick/results?sort_field=post_date&sort_dir=desc&keyword=Java))

The list just goes on and on. It's fast (okay maybe not as fast as carefully
hand-rolled C++, but used the right way it can get near to it), has lots of
mature tooling, and most importantly of all is absurdly stable.

If you're worried about start up time, you're likely worrying about the wrong
thing. Amazon, for example, is well known to scale up and down their
infrastructure on demand, and yet they're running on Java. They wouldn't do
that if application start-up time was a problem.

It's rare to see java applications that take more than 5-10 seconds to start
up unless they're insanely monolithic and pulling in large numbers of
libraries (aka enterprise stacks like Websphere), and once they're running you
leave them running. Java start up time should be the shortest part of the
whole 'spin up a new instance and start handling requests'.

