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/
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.
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!
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.
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.
There's also an excellent GIT repo of JavaEE7 samples that is maintained by RedHat here:
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.
I ran away from JavaEE toward Dropwizard and found it a much more sane platform, and much faster without the extra baggage.
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.
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)
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.
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.
It's pretty cool to take an existing Dropwizard app, change a couple of lines and every request becomes a lightweight fiber:
I find it much quicker to get started with, much better supported and better tooling.
Has that turned out to be useful in practice? Seems like a simple method for unpleasant surprises.
That said, you can also be fairly granular about you configuration (instead of the auto-config), so it's not that bad.
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):
Experimental (old) repo for dropwizard+kotlin:
Combining kotlin and guice:
My plan is to add more to it and eventually cover all the features of Dropwizard.
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:
Cant wait to upgrade to use v0.8.0 :)
It really works much better when creating a REST API for access by apps or separate front-ends (e.g. a JS SPA).
Its possible to use play framework in the same way as dropwizard is used, if you just ignore Plays server side scala templates.
If you change any signatures (should be most of the time) you need Jrebel.
Especially the "Processes" factor.
"Execute the app as one or more stateless 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.
I really loved the Play v1.x framework minus the hard to debug part.
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.
Any reasons you want or are allowed to share?
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!).
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 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.
Hats off to you Adam Jordens & Cameron Fieber :)
Development, testing, deploying, and monitoring the way it was supposed to be.
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.
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!)
And for that matter I really appreciate Go and its simplicity.
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.
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 :)
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.
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...)
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/)
Facebook (https://www.facebook.com/careers/department?dept=grad&req=a0... https://www.facebook.com/careers/department?dept=grad&req=a0...)
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'.