I've recently been in the market for a Java Web framework and have settled on Play. There are a lot of things I really like about it. I have no problem with the Play developers going "off the reservation" (as far as JEE goes).<p>I'm finding some things are a bit awkward, particularly around templates and routing. Also, the documentation while good is lacking in other parts.<p>Play is a very prescriptive framework but only on a couple of choices do I have an issue.<p>The first is about transactions. Each HTTP request is a transaction. Generally I'm fine with this but you need a way to override or control this (IMHO).<p>Second, I like the mixin approach with controllers (@With(...)). I wish there were something similar with models.<p>Third, and this is the biggest, it doesn't integrate with Maven, which is something I'm very tempted to fork it for. There's no reason it can't be a Maven plugin/archetype, use Maven for dependencies (directly, rather than tortuous syntax in dependencies.yml), etc. Some guy has an alpha version of something like this already when I last looked.<p>Fourth, while I don't necessarily mind that controllers are static (as a way of indicating they're stateless it seems), that's actually an issue for parallellizing tests.<p>Play 2.0 is moving even further away from this and using SBT, which I've never used but heard mixed things about.<p>I can't speak to many of the specifics of this post (eg I only use Play on Linux).<p>Whatever (valid) criticisms you can level against Play I'd still far and away prefer to use it over any other Java Web framework I have used or know about.
I was surprised to see Typesafe throw its weight behind Play.<p>While I understand they need a web framework in their stack, and Play is more RoR-ish than Lift (which makes it more marketable I think), I dunno, some of the gymnastics Play 1.x used to pull off its magic seemed a little over the top to me.<p>Like using bytecode rewriting to add language-level features like properties. Yes, Java sucks, but we who use it understand that and accept its imperfections. I'd rather fix Java proper (or use Scala) than have a web framework think that it's their job to somehow fix a lackluster language.<p>Just seems like it'd lead to a lot of bloat/code in the framework that isn't "just serve this webapp as simply as possible".<p>That being said, what Play got right did look really awesome (the compilation error reporting in particular).<p>Anyway, will be interesting to see what the Play 2.x release will look like, given it looks like Typesafe is having some amount of involvement in it?
"They didn't take a patch on one occasion, and then we had a couple never-diagnosed bugs that we think could have been in the framework."<p>Fair enough, but I wouldn't switch to an inferior framework over it.
I think that any platform has some gotchas especially a 1.x version, however in my experiences with it it was fast and less boilerplate than a normal Java project and we didn't have any of these issues rolling out locally and to Google AppEngine.<p>I'd still only choose it if I had to use Java though.<p>If you can roll with Django you can roll with Play. Although, I always prefer a python microframework such as flask nowadays.<p>I also see how Play is now part of typesafe, so that could get better or worse, but it is the right direction for Java web apps to go.
A very interesting look at Play can be found in this presentation: <a href="http://spinscale.github.com/play-advanced-concepts.html" rel="nofollow">http://spinscale.github.com/play-advanced-concepts.html</a><p>The author wrote the Play Framework Cookbook and so it's a presentation from someone that can be considered a bit of an authority on Play (and not someone with an axe to grind). However, the presentation covers a bit of what worries me about Play. Play rewrites the bytecode for things like emulating properties and allowing you to pass whatever you want to the templates and have it automatically name the variables based on their local names in the calling method.<p>For me, the reason to use Java over Python or Ruby would be to move away from some of the behavior used in those languages that can make debugging and static analysis harder.<p>I've used Play for some hobby stuff (and kept up on Play 2.0). Play 2.0 seems to remove the former system for passing variables to the templates in favor of a system where templates accept certain parameters with types (a welcome change for me). However, at least the last time I played with it, Eclipse couldn't tell me what variables and types the template was expecting.<p>I guess Play leaves me feeling like it brings the magic to me without as much ease that Python and Ruby offer (or, at least, without as much familiarity). That might be changing - I think that the changes in the templating for 2.0 show a clear move in that direction. I really wish them well since it's always good to have more good options for development and there's a lot of Java already out there to leverage.
I use Play! frequently. Love it.<p>I maybe be misunderstanding her first point, but I am currently running individual unit tests in IntelliJ for one of my play apps on 1.2.4...<p>I can't speak to her other issues, I've never run in to them.
Think I should mention this link <a href="https://github.com/playframework/Play20/wiki/Philosophy" rel="nofollow">https://github.com/playframework/Play20/wiki/Philosophy</a>
Valid points about bug fixes and outstanding issues. I think the Play 2 announcement was met with a mixture of trepidation and excitement from the community. If support for 1.2.x was to decrease further then I'd be concerned.<p>For what it's worth, I've been developing a Play (now 1.2.4) app for a year now and it's been a blast. Sometimes you can see the framework's immaturity, but I haven't run into any showstoppers like the author.
As someone marginally involved with the Play project, I would like to point out that, for better or for worse, Play 2.0 is a complete reimplementation of the original design, with a new API and a totally new codebase. Play 2.0 core is now written in Scala (but also exposes a Java API) and relies much less on bytecode manipulation.
Play! is one the best things that has happened to java in the last 10 years!<p>From the post I understood that she was pissed because they did not accept her fix on testing the app from the IDE.<p>The second point was that there is a bug in the framework that they could not find... it seems though as the bug is in their application. (concurrent modification of a Map is a problem in java not Play!)<p>It's a pity to give up such a great framework for silly reasons.<p>Every time I have to switch to another framework (especially jsf) I want to shoot myself.<p>Anyway... good luck finding another good java framework.
I'm curious as to specific code examples where the author is having problems. I'm thinking about using Play! or Lift for a pet web app using Scala. Does anyone have experience using either?
I'm switching to Play 2.0 (which is yet in RC3, not yet released) and I think it's a great new framework and I understand them wanting to dedicate more resources to the new framework.
What I really like about Play is the reverse routing feature. Do you know of any other Java web framework with it?<p><a href="http://www.playframework.org/documentation/1.0/templates#Actionsor" rel="nofollow">http://www.playframework.org/documentation/1.0/templates#Act...</a>
and
<a href="http://www.playframework.org/documentation/1.0/routes#reverse" rel="nofollow">http://www.playframework.org/documentation/1.0/routes#revers...</a>
Play made it very very easy for me to target a jar from php. The php-java bridge at the time would start and stop the jvm with every request (I dont know how it stands up today). I did some research and was able to stand up a play server whose routes reflected classes/methods in the jar in about 20 mins.<p>Are there other play-like frameworks for java?
Author makes great points; refusing to accept a (tested) minor patch to how tests are run should be a no-brainer because of the low threat to existing systems. One thing that was not clear to me (being unfamiliar with Play or Java at large) was wether the HashMap bug was intrinsic to Play or to Play's use of a Java library...
I looked into Lift. Steep learning curve. It would be ok for a single person, but a large team coming up to speed on Lift/Scala looks hard. Then I decided to stick with what I know best Ruby/Javascript/Node.
This confirms my bias against frameworks in general and in fact against reusing more code than necessary. And no, I would not write an encryption library myself or re-implement the HTTP protocol.<p>But the disparity between what web frameworks actually do for me in any particular application and the amount of layers and dependencies they introduce boggles my mind.<p>[Edit] If you use maven try mvn dependency:tree
While OP has met some problems, I don't see how these would drive him away. I'm curious what framework he's moving to.<p>OP is looking for a silver bullet and there ain't one. Play! is an open source project, so the developers didn't have time to deal with his patch and he got upset. People forgot OS devs don't get paid for their work. Be a little bit more appreciative.
cmiiw, but imho play is too similar with others web framework, like rails.
i'd prefer scala community to push lift instead.
lift has some great ideas, and has many things to improve.