Here’s my list, of course, with some duplications
-
breaks backward compatibility (it’s a rewrite from scratch)
-
core programmed in scala vs java (got to learn scala to collaborate)
-
scala for templates (but work is being done on groovy templates as a module, to ease migration), so you have to specify the type of each parameter
-
sbt console instead of python scripts
-
sbt for solving dependencies instead of built-in solution (play dependencies command)
-
modules availability, it will obviously take some time to migrate them all…
-
for java, it favours ebean in place of hibernate (but you’ll be able to use hibernate)
-
for scala, comes with anorm (but you’l be able to use other libraries)
-
more modular, easier to pick other components
-
more type safety – views and even routes are checked at compile time
-
better performance
-
typesafe support, it’s part of typesafe stack
-
less magic, not so much bytecode generation and similar stuff
-
more standard, (play projects are just standard sbt projects)
-
different controller API (more verbose, IMHO) you can compare a simple play 1.x crud controller with a similar play 2.0 one
-
scala is a first class citizen, but java is equally supported (has native API for each of them)
-
hot recompiling is slower (it’s still on beta, let’s hope they solve it)
-
scala IDE support is not as mature as java’s (but it’s evolving nicely)
-
async support delegated to akka
-
better prepared for different kinds of datasources, like nosql dbs
For more info have a look at play 2.0 page (spanish translation available here) and the RC1 documentation
Anyway, I think the main difference is that play 1.x tried to build it’s own stack while escaping away from j2ee, now they are part of a new and alternative stack, based on scala, akka, sbt and with the support of a company like typesafe…