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.
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!
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.
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!
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.
> 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.
> 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.
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.
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 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.
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)
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.
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.
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.
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.
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.
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:
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.
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).
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.
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
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).
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.
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.
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.
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.
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!).
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.
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.
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)
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.
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.
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!)
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.
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 :)
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.
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'.
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/