Dropwizard 0.8.0: Java framework for ops-friendly, high-performance web services(dropwizard.io)
dropwizard.io
Dropwizard 0.8.0: Java framework for ops-friendly, high-performance web services
http://dropwizard.io
23 comments
What's the primary win of doing this? Isn't DW still tied to Jetty which has a more traditional threading model?
Pardon my ignorance, but could you talk a little more about what you meant here? What non-traditional/advanced threading models are you referring to? Any reading material links would be much appreciated! Thanks!
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-l...
I totally agree but Jersey 2.x and Dropwizard still support Java 7, so the examples should also work with Java 7.
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.
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.
> 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 cost of having a choice is having to make a choice. Look at the number of concepts someone coming to the ecosystem totally fresh has to learn here. Not only that, look at the number of choices they have to make without understanding the trade-offs they might be making, or even whether they'll ever have to care. All these things you mention are added cognitive load which, for a large number of applications, will end up being totally irrelevant.
Dropwizard looks to me like a solid 80/20 solution. Think of all the apps out there which get deployed to tomcat, are the only thing which will ever be deployed to that tomcat instance, and just never have to grow past a single machine, or even a single developer. What value is tomcat (or glassfish, or whatever) actually adding in that situation? I'd argue that it's pure overhead. An in-process HTTP server running under a classic UNIX process supervisor like runit or daemontools would do just as well. Maybe there are babies being thrown out with the bathwater here, but the way forward isn't to highlight all the extra work a developer has to do to find them.
The cost of having a choice is having to make a choice. Look at the number of concepts someone coming to the ecosystem totally fresh has to learn here. Not only that, look at the number of choices they have to make without understanding the trade-offs they might be making, or even whether they'll ever have to care. All these things you mention are added cognitive load which, for a large number of applications, will end up being totally irrelevant.
Dropwizard looks to me like a solid 80/20 solution. Think of all the apps out there which get deployed to tomcat, are the only thing which will ever be deployed to that tomcat instance, and just never have to grow past a single machine, or even a single developer. What value is tomcat (or glassfish, or whatever) actually adding in that situation? I'd argue that it's pure overhead. An in-process HTTP server running under a classic UNIX process supervisor like runit or daemontools would do just as well. Maybe there are babies being thrown out with the bathwater here, but the way forward isn't to highlight all the extra work a developer has to do to find them.
Glassfish or Wildfly add value when the application uses JavaEE APIs. With a Tomcat or Dropwizard approach you have to piece together a bunch of 3rd party JARs to provide these APIs. You have to maintain this etc. With the app server the libraries are already bundled in there. Sure there may be more then you end up using but come one we are talking 10s of MBs here which in this day and age is nothing for most environments. Also startup times with these App servers aren't affected because they only startup the containers which are used by your application. My Glassfish instances start up in around 2ms with an app that uses JPA, Servlet, JAX-RS, EJB. I'd rather spend my time building the app and not spend time piecing together my Tomcat environment.
JavaEE has some truly terrible specs in it, particularly JSF and CDI. I also haven't seen a great deal of cohesiveness in the platform, e.g. when EE6 was released JSF's injection system only partially supported CDI (ViewScope for example wasn't supported) and there were other major problems such as unclear serialization requirements for JSF scopes breaking session management. I could also go on a long rant about JPA/Hibernate but that is an entire topic of it's own. Generally speaking I got the impression that each standard mostly worked on it's own with interoperability with other specs being a bit of an afterthought and that there was very little going on in terms of building an overarching, integrated, vision for the platform.
I ran away from JavaEE toward Dropwizard and found it a much more sane platform, and much faster without the extra baggage.
I ran away from JavaEE toward Dropwizard and found it a much more sane platform, and much faster without the extra baggage.
Dropwizard is basically Jersey (JAX-RS) running on top of Jetty (Servlets), with an integrated monitoring library (Metrics), which is not standardized (but neither is any other). So Dropwizard is very much in line with the standards-based approach.
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!
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!
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.
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.
> 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.
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.
Check out the JavaEE tutorial from Oracle http://docs.oracle.com/javaee/7/tutorial/ and the 1st Cup 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
There's also an excellent GIT repo of JavaEE7 samples that is maintained by RedHat here:
https://github.com/javaee-samples/javaee7-samples
I'd rather use a careful selection of libraries that provide me a single executable to run than have to work with OSGI or a JEE container.
Well, Java EE can be (is) overwhelming. This is a nicely curated list of quality libraries and feels more like one than like a framework.
I think that the Java folk would do well to promote such things as well as Java EE, since they cater to different market.
The Node.js guys have demonstrated that there is a market for "arbitrary assemblies" and if for whatever reason Java does not promote projects such as this it will lose those developers entirely: I doubt they will be willing to start using Java EE on day 1.
I think that the Java folk would do well to promote such things as well as Java EE, since they cater to different market.
The Node.js guys have demonstrated that there is a market for "arbitrary assemblies" and if for whatever reason Java does not promote projects such as this it will lose those developers entirely: I doubt they will be willing to start using Java EE on day 1.
You're still basically using many of the libraries you're mentioning - but personally I shun (most of the) JEE in preference of lighter weight approaches. If you need more of the heavy weight libraries / environments, it's (usually) not a big deal to migrate.
I don't agree with some of the choices of DropWizard, and it's not something I'd use on my own projects - but as an opinionated "here's a way to get started efficiently" approach, I think it's not bad. For some developers, getting a decent base to start on is quite a daunting experience.
Then again, if someone starts saying "must have X years experience with DropWizard" I think I'll probably snap.
I don't agree with some of the choices of DropWizard, and it's not something I'd use on my own projects - but as an opinionated "here's a way to get started efficiently" approach, I think it's not bad. For some developers, getting a decent base to start on is quite a daunting experience.
Then again, if someone starts saying "must have X years experience with DropWizard" I think I'll probably snap.
And forcing OSGi induced brain damage on someone is just cruel. After years working with that, there's absolutely NO way I'm ever doing that again.
The number of projects that don't work (mainly classloader issues) and/or had to be customized to work on it is enough of a barrier for me to never use it again. And the benefits it conferred were so minimal that the cost/benefit ratio was astronomical and completely unjustifiable. (Maybe things are different on massive teams though)
The number of projects that don't work (mainly classloader issues) and/or had to be customized to work on it is enough of a barrier for me to never use it again. And the benefits it conferred were so minimal that the cost/benefit ratio was astronomical and completely unjustifiable. (Maybe things are different on massive teams though)
I've also suffered a lot of pain in trying to get libraries that were not design for OSGi (i.e. legacy) to work well.
However, when having the luxury of implementing a clean set of services from scratch, OSGi is lovely. We run a large OSGi based system in production, and the modularity, hot-deployability, strong-typing-with-contracts, etc is just lovely.
I certainly won't try to say that OSGi is simple, but for complex systems that have to evolve over a long time span, it solves problems no other environment even nearly does.
However, when having the luxury of implementing a clean set of services from scratch, OSGi is lovely. We run a large OSGi based system in production, and the modularity, hot-deployability, strong-typing-with-contracts, etc is just lovely.
I certainly won't try to say that OSGi is simple, but for complex systems that have to evolve over a long time span, it solves problems no other environment even nearly does.
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/quasar/
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/quasar/
For those who aren't familiar - have a look at this tutorial http://blog.paralleluniverse.co/2015/03/09/up-and-running-wi...
And it's hard to overstate how huge this is. If you need to write a server that transports gigabytes of data in a stream, and you want to reuse IO pipelines the same way for small data and data-too-large-to-malloc, Quasar's fibers make that possible. Without them, you're stuck in either two-implementations land or callback hell.
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/
I find it much quicker to get started with, much better supported and better tooling.
I find it much quicker to get started with, much better supported and better tooling.
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.
Has that turned out to be useful in practice? Seems like a simple method for unpleasant surprises.
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.
That said, you can also be fairly granular about you configuration (instead of the auto-config), so it's not that bad.
You don't have to use them, but it's really great for getting started. You can fine tune these by excluding pieces you don't need to auto configured.
http://docs.spring.io/spring-boot/docs/current/reference/htm...
http://docs.spring.io/spring-boot/docs/current/reference/htm...
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/rele...
The move to Jersey 2.
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....
If you're interested in a Guicier 'framework' inspired by Dropwizard, take a look at GWizard... https://github.com/gwizard/gwizard
Interesting, I'd never seen this. For what it's worth, early Dropwizard versions used Guice heavily. We yanked it out because we found the indirection of dependency injection wasn't buying us much. Subsequently, others have put it back in through the use of modules (i.e. https://github.com/HubSpot/dropwizard-guice).
I won't repeat what is here: https://github.com/gwizard/gwizard#whats-wrong-with-dropwiza...
In order to make this reply have a bit more substance than just a link, the idea of using Guice is pretty neat if you think about unit testing your code. Instead of letting the container (jetty) instantiate the webapp, let Guice do it.
This means that you can run tests without firing up the container. In other words, no need to test through the http layer by making requests to a web server. Additionally, by removing a rather large layer of code, tests run much faster.
Instead, now you write your tests directly against your Resource class methods (yea static compiled code!). Building up routes, query strings and POST requests is a thing of the past. No need to mock your data layer either since you can test against a real in-memory database.
Here is an example of what I'm talking about: https://github.com/gwizard/gwizard-example/blob/master/src/t...
In order to make this reply have a bit more substance than just a link, the idea of using Guice is pretty neat if you think about unit testing your code. Instead of letting the container (jetty) instantiate the webapp, let Guice do it.
This means that you can run tests without firing up the container. In other words, no need to test through the http layer by making requests to a web server. Additionally, by removing a rather large layer of code, tests run much faster.
Instead, now you write your tests directly against your Resource class methods (yea static compiled code!). Building up routes, query strings and POST requests is a thing of the past. No need to mock your data layer either since you can test against a real in-memory database.
Here is an example of what I'm talking about: https://github.com/gwizard/gwizard-example/blob/master/src/t...
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
Experimental (old) repo for dropwizard+kotlin:
https://github.com/arteam/kotlin-dropwizard
Combining kotlin and guice:
http://java.dzone.com/articles/kotlin-guice-example
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
Experimental (old) repo for dropwizard+kotlin:
https://github.com/arteam/kotlin-dropwizard
Combining kotlin and guice:
http://java.dzone.com/articles/kotlin-guice-example
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
My plan is to add more to it and eventually cover all the features of Dropwizard.
My plan is to add more to it and eventually cover all the features of Dropwizard.
I find Kotlin+Clojure (or Java+Clojure) to be a winning combination, too.
I also love Ninja Framework for support of the Guice: http://www.ninjaframework.org/
FYI - I've written some bundles/extensions to DW 0.8.0 that support SOA. http://soabase.io - Service Discovery; Load Balancing REST Client; Distributed, Scoped Dynamic Attributes; Jersey-based Admin APIs; Administration Console; Configuration Utilities; Guice Integration
This looks really cool, thanks for sharing!
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
Cant wait to upgrade to use v0.8.0 :)
Cant wait to upgrade to use v0.8.0 :)
Also, saw this comparison of Dropwizard with Spring boot: http://blog.takipi.com/java-bootstrap-dropwizard-vs-spring-b... Interesting to understand the libs and flexibility each one have.
Congratulations, one of the best frameworks in the JVM land.
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.
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?
Dropwizard has support for front-end development, but I think it really shines when developing RESTful API endpoints. You can use it to serve static assets, and those can be automatically "deployed" by refreshing the page, because Dropwizard just wires up Jetty to grab files off of the hard drive. If you want to use Freemaker/Mustache for views, I don't think it currently supports any "live" development.
It really works much better when creating a REST API for access by apps or separate front-ends (e.g. a JS SPA).
It really works much better when creating a REST API for access by apps or separate front-ends (e.g. a JS SPA).
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.
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.
If you change any signatures (should be most of the time) you need Jrebel.
No, you still need something like JRebel for hot-reload of JVM classes. This framework is really designed for implementing REST APIs, it is not an MVC framework - even though it has support for serving pages using Mustache or freemarker.
Or you can take rapid application development in framework X out of the equation and use tools like JRebel.
I've tinkered around dropwizard and SBT with SBT-revolver, works like a charm.
Play framework handles this really nice without additional tools like Jrebel.
Its possible to use play framework in the same way as dropwizard is used, if you just ignore Plays server side scala templates.
Its possible to use play framework in the same way as dropwizard is used, if you just ignore Plays server side scala templates.
Seems like Dropwizard makes it possible to follow the twelve factor app approach in a Java application.
http://12factor.net/
Especially the "Processes" factor.
"Execute the app as one or more stateless 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.
http://12factor.net/
Especially the "Processes" factor.
"Execute the app as one or more stateless 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.
Is there a sample "pet shop" app?
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/)
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.
I really loved the Play v1.x framework minus the hard to debug part.
The goal is to keep it simple and not support everything and the kitchen sink (like Spring Boot and the Spring ecosystem in general does).
Why was it hard to debug?
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.
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.
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.
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.
> We then stopped instrumenting for other reasons.
Any reasons you want or are allowed to share?
Any reasons you want or are allowed to share?
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!).
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!).
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.
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.
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.
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.
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.
I wish I wasn't at work right now, but I'll bite. Watch this space...
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 :)
Hats off to you Adam Jordens & Cameron Fieber :)
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)
Why choose Metrics over Servo? Metrics lacks dimensions, which is a pretty significant oversight, IMO.
Both Metrics and Dropwizard were created by the same person, Coda Hale.
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.
What weren't you willing to yield on? If it was that metrics should have dimensions, Netflix has the stronger argument.
It looks like the author for Metrics is also the author (one of the authors) of Dropwizard.
Love Dropwizard.
Development, testing, deploying, and monitoring the way it was supposed to be.
Development, testing, deploying, and monitoring the way it was supposed to be.
Nice framework!!
Url changed from http://dropwizard.io/about/release-notes.html#v0-8-0 because this project doesn't appear to have been discussed on HN before.
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.
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.
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.
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!)
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!)
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.
And for that matter I really appreciate Go and its simplicity.
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.
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.
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 :)
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 :)
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.
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.
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.
for examples pls. There are really some, but very few.
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...)
Google (http://www.quora.com/Why-does-Google-prefer-the-Java-stack-f...)
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/)
LinkedIn (https://engineering.linkedin.com/play/play-framework-linkedi...)
Yahoo
Facebook (https://www.facebook.com/careers/department?dept=grad&req=a0... https://www.facebook.com/careers/department?dept=grad&req=a0...)
Salesforce (http://salesforce.careermount.com/candidate/job_search/quick...)
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'.
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...)
Google (http://www.quora.com/Why-does-Google-prefer-the-Java-stack-f...)
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/)
LinkedIn (https://engineering.linkedin.com/play/play-framework-linkedi...)
Yahoo
Facebook (https://www.facebook.com/careers/department?dept=grad&req=a0... https://www.facebook.com/careers/department?dept=grad&req=a0...)
Salesforce (http://salesforce.careermount.com/candidate/job_search/quick...)
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'.
If you can't cook it, it doesn't mean it's not tasty...
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...) 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/