Why Play isn’t a Java web framework
Play isn’t really a Java web framework. Java’s involved, but that isn’t the whole story.
‘Java’ refers to two different things these days, and only one of them’s a programming language. Increasingly, when people talk about ‘Java’ they are really talking about one or more aspects of the wider platform, which includes the programming language, but also the Java Virtual Machine, the Java SE SDK or the many APIs that make up the broader landscape of Java EE and in-progress JSRs. After all, we keep seeing conference presentations where the programming language isn’t Java.
More subtly, Java EE is not so much a landscape as a whole country, with its own culture - norms and values, if you like.
Eating pasta
Java EE is the land of the architectural pattern. I’m not sure which country that is, but it would have to be one where people eat a lot of pasta, with its many related code-style metaphors. What’s more, the architecture astronauts who live there have made the endless layers of lasagne architecture their national dish.
Play, on the other hand, is from somewhere else. Play 1.0 was written in Java and using Play 1.2 is currently the best way to build a web application in Java, but this has little to do with the established Java EE culture or the monsters it spawns. And even though the ugly beasts known as EJB 2.1 and JSF 1.2 eventually spawned more docile offspring (EJB 3 and JSF 2), they are merely tamed and not companions that you would want to Play with.
Emigrating to the web
The country that Play comes from is called the World-Wide Web (country code ‘www’), where people live happy joyful lives, get things done with minimal fuss, and tell jingoistic jokes about their Java EE neighbours. Fortunately for Java developers who are tired of being at the wrong end of these jokes, the immigration policy is welcoming and the language is easy to learn - an HTTP server can be as small as 1074 bytes or 4.5 mm long.
The first version of the Play framework may have been written in Java, but it had little to do with Java common practice or the established Java web APIs, and avoided the standard Servlet API entirely. Play used the Java language, but little else from the Java ecosystem, and was more heavily influenced by technologies such as PHP and Ruby on Rails. After all, Play was not written for Java EE developers: Play was written for web developers.
For example, Play 1.0 was influenced by Ruby on Rails’ project structure and user experience, which emphasised a standard pattern for getting started and having things just work. This makes a big difference to developer productivity; the opposite extreme sees teams using JavaServer Faces (JSF) spend days to ‘start-up the project’, with no two JSF applications structured the same way.
Moving on
Two years later, Play 1.2 has become so popular that it’s making Java developers who use other web frameworks look bad, because their productivity is so low. This is a good thing, because non-Java frameworks have already been doing this for years. Perhaps there is still hope for Java - as a language, a platform and a culture - to embrace the web and avoid being left behind. Until this happens, Play isn’t a Java web framework: Play is a web framework.
Conclusion
Java’s design and evolution seems to be based on the idea that the platform itself is more important than other systems that it might be used with. From a Java perspective, the web is just another external system. As with other APIs, the Servlet API has shielded Java EE from being infected by the web’s own architecture by abstracting it away into a more Java-like API. This approach is unfortunate, because the web is more important than Java - the platform and the language - and these days, a useful web framework is one whose architecture embraces the web’s, and whose API embraces HTTP.
No programming language is an island. Not even Java.