Desde 2007 hemos estado trabajando muy duro para que el desarrollo de aplicaciones web con Java sea más fácil. Play comenzó como un proyecto interno de Zenexity y fue fuertemente influenciado por nuestra manera de llevar adelante proyectos web: concentrándonos en la productividad de nuestros desarrolladores, respetando la arquitectura Web, y usando desde el principio un enfoque novedoso, rompiendo con lo que en ese momento se conocía como las "mejores prácticas de JEE" cuando tenía sentido hacerlo.

En 2009 decidimos compartir estas ideas con la comunidad e hicimos de play un proyecto open source. De inmediato la respuesta que obtuvimos fue sumamente positiva de parte de la comunidad, y el proyecto recibió muchísima difusión. Hoy en día, luego de dos años de desarrollo activo, Play cuenta con múltiples versiones, y una comunidad de más de 4.000 desarrolladores, con una cantidad cada vez mayor de aplicaciones en producción en todo el mundo.

Abrir un proyecto a todo el mundo, ciertamente implica recibir mayor información por parte de los usuarios, pero también significa descubrir nuevos casos de uso, encontrar nuevos requerimientos y enfrentarse con errores que no habían sido considerados en el diseño original. A lo largo de estos dos años de trabajar con Play como un proyecto open source hemos logrado resolver todas estas cuestiones, y también hemos podido integrar nuevas prestaciones para dar soporte a un conjunto de escenarios que no estaban previstos originalmente. A medida que el proyecto crecía hemos podido aprender mucho de nuestra comunidad y de nuestra propia experiencia, usando Play en proyectos cada vez más complejos y variados.

Mientras tanto, la tecnología y la web han seguido evolucionando. La web se ha transformado en el punto central de nuestras aplicaciones. HTML, CSS y Javascript han evolucionado a gran velocidad, tornando casi imposible que un framework del lado del servidor pueda seguirles el paso. Toda la arquitectura web está rápidamente tendiendo a funcionar en tiempo real, y los requerimientos de los proyectos de hoy en día implican que las bases de datos relacionales ya no son la única opción disponible para almacenar datos. En lo que respecta a los lenguajes de programación, hemos presenciado cambios monumentales en varios lenguajes que corren en la JVM, incluyendo a Scala que cada día cobra mayor relevancia.

Es por eso que creamos Play 2.0, un nuevo framework para una nueva era.

Las aplicaciones web de hoy en día precisan integrar datos accediendo concurrente a fuentes heterogéneas en tiempo real, de manera tal que los frameworks actuales necesitan contar con un completo soporte para trabajar con el modelo http asincrónicamente. Play 1.x fue originalmente diseñado para soportar aplicaciones web clásicas con mútiples pedidos http de rápida respuesta. Pero actualmente, se está imponiendo el modelo de eventos para conexiones persistentes, utilizando técnicas tales como comet, long-polling y WebSockets.

Play 2.0 ha sido diseñado desde el principio bajo la premisa de que cada pedido http puede potencialmente requerir un tiempo largo de respuesta. Pero eso no es todo: también necesitamos un método poderoso para programar y ejecutar tareas de larga duración. El modelo basado en Actores, es sin duda el mejor modelo disponible hoy en día para administrar sistemas con altos niveles de concurrencia, y la mejor implementación de ese modelo disponible tanto para Java como para Scala es Akka. Play 2.0 provee soporte nativo para Akka, permitiendo desarrollar sistemas distribuidos de alta concurrencia.

Una de las ventajas de usar un lenguaje estáticamente tipado para escribir aplicaciones de Play, es que el compilador puede verificar ciertas partes del código. Esto no sólo es útil para detectar errores en etapas tempranas del proceso de desarrollo, sino que también facilita trabajar en proyectos de envergadura que involucran a una gran cantidad de desarrolladores.

Teniendo la posibilidad de utilizar Scala, claramente nos beneficiaremos de chequeos del compilador más estrictos, pero eso no es suficiente. En Play 1.x, el sistema de templates está basado en Groovy, un lenguaje dinámico, razón por la cual el compilador poco podía hacer para ayudarnos, de manera tal que los errores de los templates sólo podían ser detectados en tiempo de corrida. Lo mismo ocurre con el código que vincula los distintos controladores.

Para la versión 2.0 de Play nos hemos propuesto que el framework sea aún más inteligente a la hora de validar nuestra aplicación en tiempo de compilación. Por eso, hemos decidido adoptar el sistema de templates basado en Scala, como motor por defecto en Play, incluso para los desarrolladores que elijan Java como principal lenguaje de desarrollo. De ninguna manera esto significa que sea preciso convertirse en un experto en Scala para poder escribir templates en Play 2.0, al igual que no era realmente necesario conocer Groovy para escribir templates en Play 1.x.

En los templates, Scala es básicamente utilizado para recorrer las propiedades de sus objetos con el fin de desplegar la información relevante con una sintaxis muy similar a la utilizada en Java. Sin embargo, si desea aprovechar todo el poder de Scala para escribir templates complejos, rápidamente descubrirá que Scala, al ser un lenguaje funcional basado en expresiones, es la compañía ideal para un motor de templates.

Todo esto no sólo es cierto para el sistema de templates: el sistema de ruteo también contará con validaciones en tiempo de compilación. Play 2.0 verificará en tiempo de compilación las definiciones de sus rutas, asegurando que todo sea congruente entre sí, incluyendo lo que respecta a las rutas reversas utilizadas para formar los url de cada acción.

Más aún, al ser completamente compilado, será más fácil empaquetar y distribuir los templates y archivos de rutas para ser reutilizados, al mismo tiempo que experimentaremos importantes mejoras de performance en tiempo de corrida.

Ya en los comienzos del proyecto, habíamos comenzado a explorar la posibilidad de utilizar Scala para desarrollar aplicaciones de Play. Inicialmente lo hicimos a través de un módulo, a fin de poder experimentar libremente sin impactar de lleno en el framework.

Integrar Scala en un framework basado en Java no es una tarea trivial. Gracias a la compatibilidad de Scala con Java, pudimos lograr una primera versión que simplemente utilizaba la sintaxis de Scala en vez de la de Java. Sin embargo, esta no es la mejor manera de aprovechar este lenguaje. Scala es un lenguaje híbrido que integra la orientación a objetos con programación funcional. Para aprovechar todo el poder de un lenguaje como Scala es preciso replantear todas las APIs del framework.

Sin embargo, rápidamente llegamos a un punto en el cual habíamos alcanzando el límite de lo que podíamos hacer con Scala tratándolo como un módulo separado del framework. Algunas desiciones que tomamos en las versiones iniciales de Play 1.x, como el uso intensivo de reflection y manipulación de bytecode, tornaron imposible progresar en la integración con Scala sin repensar por completo varias partes esenciales de la implementación interna de Play. Mientras tanto hemos ido creando varios componentes para Scala de gran utilidad. Como el nuevo sistema de templates, estáticamente tipado, hecho en Scala, o las nueva librería de acceso a base de datos: Anorm. Por eso hemos decidido que, para aprovechar al máximo el poder de Scala con Play, moveríamos el soporte para Scala de un módulo separado al propio núcleo de Play 2.0, el cual ha sido diseñado desde el principio para soportar nativamente a Scala como lenguaje de programación.

Java, on the other hand, is certainly not getting any less support from Play 2.0; quite the contrary. The Play 2.0 build provides us with an opportunity to enhance the development experience for Java developers. Java developers get a real Java API written with all the Java specificity in mind.

Por otra parte, Java ciertamente no recibirá menos atención en Play 2.0; por el contrario. Esta versión nos da la oportunidad de mejorar la experiencia del desarrollador Java al utilizar Play. Los desarrolladores de Java recieben una verdadera API escrita teniendo en cuenta todas las especificidades del lenguaje Java.

Desde el principio de este proyecto elegimos una novedosa manera de ejecutar, compilar e implementar aplicaciones en Play. En ese entonces, podrá haber parecido un diseño esotérico, pero era crucial para brindar una API HTTP asincrónica en vez de la API estándar de Servlets, ciclos cortos de desarrollo a través de compilación en vivo y la recarga automática del código fuente durante el desarrollo, así como para utilizar un novedoso sistema de packaging. Todo lo cual hizo que fuera extremadamente complicado hacer que Play se rigiera por los estándares y convenciones de JEE.

Hoy en día, esta idea de implementar aplicaciones web prescindiendo de un contenedor de servlets, es cada vez más frecuente en el mundo Java. Es una decisión de diseño que le ha permitido a Play correr nativamente en plataformas como Heroku, la cual ha introducido un modelo que consideramos el futuro de la implementación de aplicaciones Java en plataformas PaaS (Plataforma como un Servicio).

Los build systems existentes para Java, sin embargo, no eran lo suficientemente flexibles como para soportar este nuevo enfoque. Dado que queríamos proveer un conjunto de herramientas simples que permitieran ejecutar e implementar aplicaciones hechas con Play, en la versión 1.x creamos una colección de scripts hechos en Python que se encargaran de todas las tares relacionadas con la compilación (build) y despliegue (deployment) de la aplicación.

Pero los desarrolladores que usan Play para aplicaciones empresariales, las cuales requieren procesos de construcción (build) más específicos y deben además integrarse con los build systems en uso en sus compañías, se sentían un poco perdidos. Los script de Pyhton que proveemos con Play 1.x no pueden suplir un completo sistema de builds, y no son fácilmente extensibles ni configurables. Por eso decidimos utilizar un sistema de builds más poderoso en Play 2.0

Dado que necesitamos una herramienta de builds más moderna, lo suficientemente flexible como para soportar las convenciones originales de Play y al mismo tiempo capaz de manejar proyectos en Java y Scala, elegimos integrar sbt en Play 2.0. Esto no debería asustar a los usuarios de Play que están contentos con la simplicidad de los builds de Play. Seguiremos ofreciendo la misma experiencia simple del play new, run, start, encima de un modelo mucho más extensible: Play 2.0 vendrá preconfigurado con un script que será suficiente para la mayor parte de los usuarios. Pero que, si precisa cambiar la manera en que su aplicación es construida (build), implementada (deployed), etc., dado que un proyecto de Play será un proyecto sbt estándar, le permitirá personalizarlo y adaptarlo según sus particulares necesidades.

Esto también implica que dispondremos de una mejor integración con proyectos Maven, la posibilidad de empaquetar y publicar su proyecto como simples archivos jar en cualquier repositorio, y especialmente la posibilidad de recompilar y recargar automáticamente su aplicación o cualquier proyecto dependiente, incluso librerías Java o Scala, todo esto en tiempo de desarrollo.

Hace rato que el término "base de datos" ha dejado de ser sinónimo de "base SQL", si es que alguna vez lo fue. Muchos modelos alternativos para almacenar información están ganando popularidad, ofreciendo distintas características para diversos escenarios de uso. Por esta razón, se ha vuelto extremadamente difícil para un framework web como Play tomar decisiones acerca de las características del tipo de almacenamiento de datos a ser utilizados por los desarrolladores. Ya no tiene sentido intentar abstraer todos los accesos a datos en una clase genérica como play.db.Model, dado que es casi imposible soportar todas estas heterogéneas tecnologías con una única API.

En Play 2.0, quisimos lograr que sea verdaramente simple utilizar un driver de cualquier fuente de datos, ORM, o cualquier otra librería de acceso a base de datos sin ninguna integración especial con el framework. Simplemente queremos ofrecer un conjunto mínimos de funciones auxiliares para manejar los casos de uso más comunes, como la administración de las conexiones. Sin embargo, también nos proponemos lograr que Play siga siendo un stack completo, incluyendo herramientas por defecto que permitan acceder a bases de datos tradicionales para aquellos usuarios que no tengan requerimientos especiales, y es por eso que Play 2.0 trae incluido soporte para bases de datos relaciones a través de librerías como Ebean, JPA y Anorm.