Frequently Asked Questions

How play compares to framework X?

Nowadays, you have a very large number of choices to develop Web applications. Play being a Java web application framework, let’s compare it to other Java frameworks. Play is built for a ‘share nothing’ architecture (think about it as a Stateless framework). So it’s very different from all these Java stateful and components based frameworks like Seam, Tapestry or Wicket. It’s closer to Spring MVC or Struts (or Struts 2), but way more opinionated.

However Play is a very unique Java framework. It does not really rely on the so-called Java Enterprise standards. It uses Java but tries to push all the good things from the frameworks based on scripting languages like Ruby On Rails, Django, Pylons, Symfony, Grails, Cake PHP, etc. to the Java world. We really tried to get the best of the Java platform without getting the pain of traditional Java web development: slow development cycle, too much abstraction, too much configuration...

Please rename the ‘play’ package as ‘org.playframework’!

You miss the point. Play is not another library that you add to your servlet container. It’s really a full stack Java framework that runs your application in a standalone way. The Java package naming conventions exist to avoid name clashing when you use several different libraries from several vendors. But believe us, you will never put the play.jar library in your own project. This is not the way play works. Play is the platform. Don’t worry about that.

Why do I need python (I would prefer maven)?

We need a lot of scripts to manage Play applications, like creating a new application, running it, launch a browser, etc... Of course we could write these in Java directly. But running a Java VM for simple tasks like project creation is very slow. And Java itself is very limited when it comes to OS interaction.

Python allowed us to write these scripts in a completely portable way. It’s fast to run, easy to write and available out of the box on most systems. It’s not on Windows, that’s why we bundle a Windows Python binary with the framework.

Is play a Groovy framework?

No. Even if we use Groovy as the base technology for the Play templating system, it’s totally transparent. Also, you can’t write directly any other part of the application (such as controllers, models or other utilities) in Groovy. If you’re looking for a Groovy based framework you should have a look at Grails.

You guys don’t even know how to program in Java...

We are fully aware that we made choices that are pretty uncommon in the Java world, and that Play does not blindly follow all the so-called Java ‘good practices’. But all members of the Play teams are very experienced Java developers and we are totally aware of the choices we made and the rules we broke.

Java itself is a very generic programming language and not originally designed for web application development. It is a very different thing to write a generic and reusable Java library and to create a web application. A web application itself doesn’t need to be designed to be reusable. You need less abstraction, less configuration. Reusability does exist for Web applications, but through Web service API rather than language-level integration.

When the development time tends to 0 you can concentrate on your application features and experiment quickly, rather than try to abstract things for future developments.

Is Play fast?

Yes, Play itself is fast. But that doesn’t mean that any particular application will be fast. The embedded HTTP server, the basic routing and the controller invocation stack is very very fast. Used with a modern JVM and Just In Time compiling you can easily get thousand of requests per second. Unfortunately as your application will likely use a database, it as usual will become the bottleneck.

The biggest CPU consumer in the Play stack at this time is the template engine based on Groovy. But as Play applications are easily scalable, it is not really a problem if you need to serve a very high traffic: you can balance the load between several servers. And we hope for a performance gain at this level with the new JDK7 and its better support of dynamic languages.

Can I already use it for a production application?

Sure, a lot of people already use play in production. The 1.0 branch is now in maintenance mode, that means that we will just fix bugs and keep API compatibility in that branch.

Is library X supported?

Play is standard Java, so any standard Java library can easily be used. However keep in mind that Play does not use the Servlet API (even if you can get it work in a standard servlet container using the WAR export). So unless the library you want to use relies on the Servlet API, there won’t be any problem.

How can I help/contribute?

We use launchpad as our main development tool, and launchpad itself is very open. You can just register a launchpad account and start to contribute. You can assign any open bug to yourself, fork any play official branch to your own branch, and propose us to merge if you have fixed something.

The documentation itself is kept as textile files in the framework source repository, so you can edit it and contribute just like with code.