The upside of Spring over Dropwizard or Play (or any of the lighter touch frameworks) is that it's so much more than an MVC or REST controller framework. The report in question is literally comparing it against the entire Java EE ecosystem. Spring is not a library or a framework anymore, it's practically an entire stack that you can pick and choose from.
Play and DW are likely to be easier to get your head around than Spring, there's a lot of magic going on in there and (not unlike getting into the JS world these days) you will find that setting the thing up from scratch takes a whole lot more time than you ever would have guessed. There's 1000 ways to do the same thing and sometimes doing it one way is a real issue later on, and worst of all it may not be apparent that that is the root source of some seemingly unrelated issue.
Spring Boot aims to solve a lot of that by taking an opinionated approach to how the project should be laid out, libraries, and default configuarations- more along the lines of a .NET MVC + database, etc. There's still the same amount of complexity and configuration, it's just hidden from you until you need to dig in.
I generally use Spring Boot to start greenfield projects these days, we deploy to AWS and their extra libraries for handling and working with that save a lot of boilerplate that's so common with Java.
I would suggest you get your feet wet with either GP or DW, but don't forget about Spring Boot down the road. I've gotten to the point where I've got a stack including Vault (secrets) + Spring Config Server (distributed config application) + a fleet of various Spring Boot microservices running in Docker on AWS and they (mostly) just startup and run the way I wanted them to. It's really awesome, and wildly overkill for that proof of concept API or personal project we would be doing a lot of, but allows me to run my company without a huge team.
https://playframework.com/download#examples
Should save you some time if you're looking to get started with JPA, different libraries, etc.
Also, this doesn't really get at the strengths of Play as a reactive application. For example, here's a talk where I discuss using Reactive Streams with Play to stream video through Play. It's about two years old now:
https://www.youtube.com/watch?v=zUB7GJMe_WY
Thanks!
Definitely not all batteries included, but a great minimalist web library to get started with.
You use Groovy, but it's pretty similar to Java and there's plenty of resources to bring you up to speed.
I can't really comment on Grails 3, funnily because the applications were written before 3.x came out and we haven't bothered upgrading them yet... :) I've only taken a brief look at what's involved in upgrading them, but other stuff has always been higher priority.
It's probably worth being familiar with both versions, because Grails had plenty of adoption before 3.x came out and 2.x is still being maintained.
I have been writing Java for 10 years now. I've used many different frameworks and libraries. But now all my new projects are Spring Boot projects.
It is a very lightweight framework with support for most of the plumbing a developer might want without imposing its will on anyone.
If you are not that worried about having a REST or HTTP or TCP front-end, LMAX disruptor is amazing as well.
I have had great success with the examples from TomEE (free) + the (paid) videos from Adam Bien (I normally shun videos but lke his).
The examples from TomEE often come in the form of something you can run with a single maven command.
There is also a huge number of tutorials from the horse's mouth on the topic.
AWS Lambda now supports Java, so perhaps we could consider API Gateway, Cognito and DynamoDB/Aurora as one of the new "frameworks". Google has their own competing offering as well, e.g. Cloud Functions. Firebase deserves a special mention as a rapid development framework, although at the moment it only supports Node.js. Like many frameworks it has pros and cons, but in my opinion full-on websockets support OOTB is a pretty cool pro.. especially since Lambda/Cloud Functions/FaaS can't do websockets on their own.
Configuration generally kind of sucks to manage, you don't get some of the role inheritance you can get from standard EC2/IAM, and forget running inside a VPC.
The idea behind using something like API Gateway + a Lambda for the various end points sounds awesome in theory, but going beyond contrived examples shows that we're a long way out.
Cold start time is a known issue but frankly, not that big of a problem in practice for many apps. Definitely I feel that dismissing this out of hand (I even got a downvote) is more of an emotional reaction to something really different and new than a rational one. There's nothing contrived about implementing a REST service with FaaS -- it's just simpler. It's worth giving it a serious look even as an experienced Java developer (as I am). There are a lot of benefits to the architecture, like minimal devops and tremendous cost effectiveness.
Don't think I'm dissing Lambdas (or anything like them in a non AWS context). There's a lot to love about them, not the least of which is that for small (in time to completion, request volume, and memory usage) units of work they are significantly cheaper.
There's a config management nightmare for everything but there are known ways to answer it for a traditional server/fleet approach. Run time configuration of Lambdas is still evolving and there aren't many options to choose from that are much better than just deploying the code and config as one as part of a delivery pipeline. It's workable now, but there are gaps. There aren't any gaps with running your own applications, it's literally what's always been done. There are certainly pain points, but the problem is already well understood.