Play! is by far the best web framework I've ever seen for Java.
It is as hot as node.js and socket.io combined! I can't really recommend it highly enough.
* A life-changingly fast edit-test loop. (Faster than Django!)
- Excellent beaning for form parameters (no longer have to mess around with Integer.parseInt(getParameter("objectId")))
- Libraries that obviate the crufty old ones, e.g. instead of Apache WebClient, just use WS.url("google.com ").get(). It has OAuth, Emailers, etc.
- Support for new technologies, e.g. WebSockets
- Support for non-blocking IO in imperative-looking code. (e.g. you can "waitFor()" a Future, which will cause Play! to suspend your request until the Future is ready, reusing your Thread for another request, and resume where you left off)
- Much better interceptor model than J2EE (can apply interceptors to your entire class, to individual methods by annotating, e.g. @Before, @After, @Finally)
- A routes file instead of web.xml
- Large selection of community modules to do everything from rendering your template as PDF to inlining CoffeeScript in your page.
- A framework for running scheduled jobs and for triggering asynchronous jobs from web requests.
- The default Groovy templates are powerful, but notoriously slow. The template system is supposed to be pluggable, but I haven't yet found a templating technology that feels perfect.
- The heavy use of reflection and bytecode manipulation is what makes things so convenient, but I can also imagine it being a turn-off for some.
- The Play! codebase is very light on comments.
Give it a shot if you haven't already.
- Play! Fanboi
One of the concerns internally was that it has a much smaller community than more established frameworks - have you found this to be an issue?
Also, it sounds like you used it for a reasonably large project. How does code organization and maintainability compare with traditional frameworks?
Code organization is basically up to you. The default organization is the typical MVC directories, but that's not a requirement for anything (and you can add other directories / subdirectories as you wish).
The one caveat on code organization is that Play! hot-compiles all code under its /app directory. My approach to sharing code with other non-Play! projects is to use "ant" to build a jar, and add that to the classpath of my Play! project. The end result is that you get hot-compilation of everything specific to your webapp, but you have to use ant to build code outside of that. I find it works fine in practice, and if it's a standalone app then you never have to leave hot-compile land.
Maintainability is great -- Play! makes heavy use of ThreadLocals, so you can access the current Request, Response, template arguments, etc etc no matter where you are, without having to pass it all around as method parameters. So making helper methods is super easy. We created a "helpers" package to put functionality shared across Controllers and can follow DRY without a problem.
One more question - you mentioned the Groovy templates are slow, do you mean as in execution time? Have you run into any performance problems?
Also, the documentation is absolutely first rate. I think this really counts for a lot. Compare the Play documentation with, say, Struts2. Chalk and cheese.
Play really is as easy/fun to use as people say; rolled out a handful of simpler apps (few weeks worth of work) and Play! seems to always have some easy solution to every problem I've run into... never needed to dig deep on the API to work around or design around anything (I seemed to do this a lot with JSF and Wicket).
I've been hoping for a Java-based framework that can compete with the Rails and Djangos for a while. I made the mistake of investing my time in Grails, and really regret it.
I've been wanting to use Scala for building web apps, but Lift reminds me of J2EE all over again. Hopefully Play! with Scala can get it right.
FWIW, I've been using Grails extensively for the past year or so, and have absolutely loved the experience.
jobs at gushhq.com or peter @ gushhq.com. http://blog.getgush.com You have to be in Canada.
It's been not too bad to use.
I'd recommend Play! over Lift if:
* You just want a data entry / CRUD style app
* You prefer MVC architecture
- Play! will feel pretty familiar if you've used Rails
* You don't know Scala
* You already know Scala
* You want to build more "reactive" apps
- Lift has excellent AJAX / Comet support built in
* You enjoy trying new ways of doing things
- Lift has many unique features, there aren't many similar frameworks
I should add - you can do AJAX & Comet in Play!. You can do MVC in Lift! One framework is just more adept than the other by default in their respective arenas.
* no code in the view
* there is more than one way to use Lift
* code in view: similar to erb files in rails
pros and cons about code in the view: http://scalate.fusesource.org/code-in-view.html
Well lets say on my next project I'll give "code in view" a try :)
I tried to build something with it about 6 months ago. Every piece of sample code I found used a different combination of classes/frameworks, and it was in the middle of an ORM switch from Mapper to Record (or something). It was a disaster, and I gave it up after a couple days of frustration.
Play! is stateless.
Both have great communities - Lift has a slight edge in mindshare because of Foursquare.
Its quick and easy to get started on and stays out of your way most of the time. Luckily it has a 'eclipse mode' otherwise I think that would have never been a reality.
Search stack overflow for java payment gateway library and you will find my as-yet unanswerred question. The java community seems much more intent on monetizing libraries and having annoying restrictions - in ruby shit is just out there.
I actually much prefer Scala as a language (although Play support was not ready then). Ruby is a dog in many ways and common practices in the ruby world are completely against my philosophy, but hey, it works and I know it.
I'd definitely recommend checking out Play and Scala.
The question seems pretty specific:
I'm looking for a Java payment gateway library similar to the Rails active_merchant or the libraries available on many other platforms. I've been surprised that I've been unable to find one. I'd like something that supports the major gateways and providers, like Paypal, Google, Amazon, and some direct merchant account providers like Authorize.net.
Does such a thing exist in the open source world?
Wrap Active Merchant in a lightweight web service which exposes a RESTful API that Java (or any language) can talk to.
Or you can use warbler to bundle your ruby app into a deployable WAR file: http://caldersphere.rubyforge.org/warbler/
If you do manage to get it working, it would be great to have a blog post on it.
Using JRuby or a REST API to a Rails app is the kind of complication to an app you desperately want to avoid.
Active Merchant "raison d'être" was Shopify's requirements for a simple and unified API to access dozens of different payment gateways with very different internal APIs. Abstracting the APIs for dealing with credit cards and payment processors was core to Shopify's business, and they open-sourced what could have easily been kept closed. This abstraction is hard work, not the kind of work I want to do, and I'd rather use their robust library than roll my own or use another poorly-tested one.
We package and deploy Active Merchant in a single, stand-alone .jar file. We don't use Rails (Active Merchant works excellently as a stand-alone library). It's not as complicated as you think.
Btw, I was a java developer for 6 years. I was looking forward to type checking, but the closed community was too much to handle after experiencing the ruby world.