JSP is just awful - taking PHP and trying to fit it into Java somehow. It's just terrible and needs to be phased out ASAP. (EDIT: Probably too harsh.. JSP works in the same way PHP works: it powers most of the web, and it does a grudgingly good job. The ease of plopping in some dynamic content into am html website made by a designer should not be discounted lightly for small websites. Probably best to just use PHP and not JSP in this use case though...)
GWT/GAE/AppScale mix is my preference. You can share code across server and client. Building RESTful services is a dream with Jersey on the server/thick client, and RestyGWT in the browser. The GWT compiler produces some very well performing javascript (only a bit slower than highly optimized libraries, but feels faster than nearly all webapp javascript). GWT also has incredibly good tooling support in automatic sprite sheet creation, compiled CSS styles, uibinder for declarative layouts, etc. The downsides are (1) java language, so no functional programming and (2) compile time can get nasty when you head in the millions-lines-of-code arena. GWT team is seemingly working on speeding up the dev cycle with SuperDevMode and that.
Play framework is most similar to the ruby on rails approach and works incredibly well for your standard webapp. The support for Comet and WebSockets are particularly nice and making very dynamic 'push' webapps is the real strongest point. The tooling can get pretty annoying at times with features/bugs, but it is steadily improving. The biggest downside to Play is that it is in a 'hipster phase' currently with the release of Play 2. This means both a huge surge in interest, but that same surge can be a curse when it drops out of 'hipster' mode in the future and loses devs. Numerous promising frameworks/languages have hit this problem and never really recover when the 'fashion' changes.
GWT, for example, has long since fallen out of fashion but continues to be heavily developed because of the huge and profitable existing user base inside Google (Adwords, etc), guaranteeing it active development for awhile to come.
I'd argue that Play will circumvent this "hipster phase" issue for (at least) these three reasons:
(1) The ubiquity of the Java/JVM ecosystem paired with the interest in a alternative to Java will keep the functional JVM Langauges like Scala/Clojure in high demand.
I use Weld for a side project, had hard time getting it to work with JRebel, and the redeployment is a headache, also hotswap didn't work for proxied classes (Injection / CDI). The JEE 6 stack, somewhat affected by Gavin King (author of Seam and Hibernate) is not that bad, it's just not that cool anymore, same way that Spring MVC is less cool (just because there are arguably easier and more rapid frameworks such as Play) and by saying less cool I mean less fun and less fun means to me less productive.
We heavily use the Play framework at https://balancedpayments.com where we wrap various Java SDKs over an internal JSON API to communicate to our various banks / processors from our Python backends.
It is ABSOLUTELY a pleasure to use. I did a thorough analysis of all the Java frameworks that I could use and Play is what I landed on. It gets out of your way and if you use an IDE like IntelliJ IDEA - you will develop on the same speed with something like Django or Rails.
Play has made me really enjoy Java again since during our CS courses and my time as a high frequency algorithmic developer on Wall St was spent in C++/Python, I never needed to really use Java.
Now, I can tell you that I have new found respect for Java and I can't speak highly enough about the Play framework. I'm happy to elaborate a bit more on our use of it -- feel free to contact me via email in my profile.
I "want to do a project with it" and "want it to succeed" more than I "like it as a framework because I've done production projects with it"
Why? Since it's in the official typesafe stack (a company founded by Scala's creator to promote it and it's ecosystem commercially), based on concepts taken from RoR, has rapid deployment without the need to pay JRebel 100$ per developer, and is supporting both Scala and Java.
So I see it as "finally something good happening to those who wait".
It's the only way enterprises can start doing modern web development without giving up on their existing investment in the Java / Spring / Hibernate stack.
My view on it? I can't wait to get a work related project done with it.
Lift is also an interesting option (Scala only though), but you asked about Play. Lift has it's learning curve, but it's creator claims it is better than Play in almost any aspect, and many tend to agree, but I don't know enough to judge...
As someone who has used Lift in production on a non-trivial webapp for the last 18 months, and has used Play 1 and 2 in both Java and Scala for side projects, I would not recommend Lift.
The "the-view-is-the-controller" approach encourages a messy blend of logic and presentation, with lots of HTML ending up in your Scala code.
It's stateful in the extreme, using opaque callback identifiers to identify serialized closures, so rather than having a nice, clean, easy to reason about boundry between your app and the outside world (your routes file, controller methods, whatever), any code anywhere could be invoked by someone clicking something in their browser.
Validation now needs to be enforced in the models, since you no longer have a single place to check it as it comes in. It goes beyond that and embeds rendering logic in models, which have to toForm method which generates HTML.
The extreme statefulness also means you lose everything when you roll a server, you need sticky sessions, you spend way too much time GC'ing and you need far more RAM/user.
I work in an enterprise-ish setting and regularly develop with Spring MVC, Struts and Rails on the server side. More recently have been using Play 2.0/Scala (I must admit I have not had a Play app make it to production yet).
I find it more productive, like rails in dev mode you can make a change, refresh the browser and watch what happens. This kicks arse compared to hot deploy/in place deploy with Java, or even to JRebel. The main advantage I find over the others in terms of framework features is the non blocking/asynchronous constructs provided out of the box. For anyone new to it, it's also worth noting that from 2.1 (almost out) you can integrate with Spring, and that there seems to be a healthy collection of 3rd part modules for it, ie for stuff like oauth.
I could go on for ages, but essentially I prefer it to the other frameworks Im familiar with...
1. JSP
2. GWT/GAE/AppScale
3. Play
JSP is just awful - taking PHP and trying to fit it into Java somehow. It's just terrible and needs to be phased out ASAP. (EDIT: Probably too harsh.. JSP works in the same way PHP works: it powers most of the web, and it does a grudgingly good job. The ease of plopping in some dynamic content into am html website made by a designer should not be discounted lightly for small websites. Probably best to just use PHP and not JSP in this use case though...)
GWT/GAE/AppScale mix is my preference. You can share code across server and client. Building RESTful services is a dream with Jersey on the server/thick client, and RestyGWT in the browser. The GWT compiler produces some very well performing javascript (only a bit slower than highly optimized libraries, but feels faster than nearly all webapp javascript). GWT also has incredibly good tooling support in automatic sprite sheet creation, compiled CSS styles, uibinder for declarative layouts, etc. The downsides are (1) java language, so no functional programming and (2) compile time can get nasty when you head in the millions-lines-of-code arena. GWT team is seemingly working on speeding up the dev cycle with SuperDevMode and that.
Play framework is most similar to the ruby on rails approach and works incredibly well for your standard webapp. The support for Comet and WebSockets are particularly nice and making very dynamic 'push' webapps is the real strongest point. The tooling can get pretty annoying at times with features/bugs, but it is steadily improving. The biggest downside to Play is that it is in a 'hipster phase' currently with the release of Play 2. This means both a huge surge in interest, but that same surge can be a curse when it drops out of 'hipster' mode in the future and loses devs. Numerous promising frameworks/languages have hit this problem and never really recover when the 'fashion' changes.
GWT, for example, has long since fallen out of fashion but continues to be heavily developed because of the huge and profitable existing user base inside Google (Adwords, etc), guaranteeing it active development for awhile to come.