Play! framework 1.1 publicado

Ya está disponible la versión 1.1 de Play! Framework. Una herramienta para hacer aplicaciones web con Java de forma rápida. Para ello es parecida a herramientas como Grails o Spring Roo en que genera código a partir de comandos en una consola. Pero lo que hace resaltar a esta herramienta es que está enfocada a tener un gran desempeño.

Para ello hace cosas como uso de métodos estáticos, no usa el estándar de Servlets y se han montado su propio API para comunicarse con la web, etc.

En esta nueva versión, han evolucionado bastante. De entrada han agregado al testrunner con el que cuenta, un browser no gráfico, para poder ejecutar las pruebas de selenium que te genera, en ambientes headless (útil para servidores de CI).

Han migrado de  usar el servidor HTTP de Apache Mina al de Jboss Netty. Sobre todo por temas de bugs; además este movimiento les permitirá soportar websockets en un futuro.

Se ha desacoplado el framework de JPA a través del API play.db.Model. Esto permitirá soportar otras tecnologías de datos como NoSQL. De hecho ya se ha publicado un plugin para usar MongoDB con Play explotando este nuevo API.

Soporte para Scala, a partir de esta versión, se puede usar Scala en lugar o como complemento de Java. De hecho en la JavaOne, los desarrolladores de Play! mencionaron que se están pensando muy seriamente que la versión 2 sea 100% para Scala.

Contenedor nativo para Glassfish. YA es posible hacer deploy de aplicaciones en Glassfish. Dado que Play! no usa el contenedor de Servlets, se ha desarrollado un contenedor para poder hacerlo dentro de este server de aplicaciones.

Soporte para OAuth. 

Entre muchas otras nuevas características. Podéis revisar la lista completa en las notas de la versión. Play! se ha posicionado últimamente como una gran alternativa para RAD en Java. Esta versión no es una versión menor a pesar del nombre y viene a completar las features pedidas por los usuarios.  

javatuples 1.0 liberado

javatuples es una librería Java que da soporte a tuplas. En ocasiones, uno necesita devolver varias cosas desde un método Java (una cadena de caracteres y un entero, por ejemplo). En este momento uno tiene dos opciones: usa una lista, y por lo tanto convierte el método en algo que realmente es no type-safe, o se crea una clase con dos campos: un entero y una cadena de caracteres, y devuelve una instancia de esa clase.

La segunda solución es bastante recurrida. Tanto Netbeans como Eclipse, por ejemplo, tienen dentro de su base de código clases en plan Tupla, para permitir devolver dos cosas desde un método.

 javatuples proporciona varias clases genéricas que permiten envolver desde 1 hasta 10 elementos. De este modo, se simplifica la tarea de devolver múltiples cosas desde un método. Las clases que proporciona son:

• Unit<A> (1 element)
• Pair<A,B> (2 elements)
• Triplet<A,B,C> (3 elements)
• Quartet<A,B,C,D> (4 elements)
• Quintet<A,B,C,D,E> (5 elements)
• Sextet<A,B,C,D,E,F> (6 elements)
• Septet<A,B,C,D,E,F,G> (7 elements)
• Octet<A,B,C,D,E,F,G,H> (8 elements)
• Ennead<A,B,C,D,E,F,G,H,I> (9 elements)
• Decade<A,B,C,D,E,F,G,H,I,J> (10 elements) 

Todas estas clases son typesafe, inmutables, serializables, interables, e implementan equals() y hashCode() y toString(). Con ellas podríamos definir un método como:

public Triplet getYearMonthDay() {

        ....

}

y devolver el día, el mes y el año de la fecha. Javatuples se distribuyen bajo licencia Apache.

¿Qué os parece esta librería? ¿El problema que está resolviendo es un problema que habéis encontrado en alguna ocasión? 

Call for Papers para el Spring I/O Madrid 2011

Después del éxito que tuvimos en el Spring 2GX Day (Madrid) y en el Spring I/O (México), volvemos a la carga con la siguiente edición. En esta ocasión, vamos a extender los días del evento (van a ser dos en vez de uno) y los tracks (mínimo dos), con lo que va a haber cabida para más contenido y más expertos.

En esta ocasión, vamos a abrir un call for papers para aceptar peticiones de presentaciones, así que cualquier persona que esté interesada en dar una charla o taller de Spring, Groovy/Grails, Cloud...puede enviarnos su petición a través de la web del evento. La fecha límite es el 18 de Diciembre del 2010.

Igualmente, tenemos abiertas las peticiones para patrocinadores y expositores. Los interesados podéis encontrar la información de contacto también en la página web del evento.

El Spring I/O Madrid 2011 se va a celebra en el mismo sitio que el Spring 2GX Day, la Escuela Politécnica Superior de la Universidad CEU San Pablo durante los días 17 y 18 de Febrero.

¡Iros reservando los días!

Resultados de las elecciones del Java Community Process

Se acaban de celebrar las elecciones al Java Community Process. En el comité ejecutivo para Java SE /EE los puestos de Apache y Red Hat han sido ratificados, y Google y Eclipse han vuelto a ser elegidos. En el comité ejecutivo de Java ME, los puestos de Research in Motion (RIM), Samsung y TOTVS han sido ratificados, y  Apix y Stefano Andreani han sido elegidos. El último de éstos es una persona que va a pertenecer al comité ejecutivo a título individual.

Una de las novedades en la elección es que el favorito de Oracle para formar parte del comité ejecutivo de Java SE/EE, Hologic, no ha sido elegido. Hologic es una empresa que no juega ningún papel relevante dentro de la plataforma Java. Pero es un partner importante de Oracle. Este movimiento, feo pero esperado (aunque no es deseable, es normal que Oracle trate de llevar el Java Community Process en la dirección en la que le interesa) le ha salido mal a Oracle.

Esto ha hecho que todavía haya un sitio vacante en el Comité ejecutivo de Java SE/EE, sitio para lo cual Oracle propondrá en breve algún candidato que tendrá que ser ratificado por la comunidad.

Aquí tenéis los resultados detallados de la elección, y aquí la composición actual de los comités ejecutivos.

La introducción de los query "typesafe" a JDO

En DataNucleus hemos desarrollado una versión de JDOQL de tipo "typesafe" en el estilo de QueryDSL (y con un poquito de colaboración con la gente de QueryDSL). La intención es introducirla en JDO3.1. En este blog post (en ingles) damos unos ejemplos de lo que es posible con DataNucleus SVN. Como el blog está en ingles, aquí hay un ejemplo,

TypesafeQuery<Product> tq = pm.newTypesafeQuery(Product.class);
QProduct cand = (QProduct)tq.candidate();
tq.filter(cand.value.lt(40.0)).orderBy(cand.name.asc());
List<Product> results = tq.executeResultList(true, cand.name, cand.value);

Es igual que escribir

SELECT this.name, this.value FROM mydomain.Product WHERE this.value < 40.0 ORDER BY this.name ASCENDING

pero permite la refactoración de las clases y campos. En nuestra opinión esta forma es mas elegante que el JPA Criteria, y el usuario necesita menos lineas de codigo para escribir su query. Como JDO da soporte a cualquier lenguaje de query, pensamos de incluir una versión para JPQL tambien en el futuro.

¿Que piensan ustedes? ¿Hay algo en JaQu, LiquidForm, QueryDSL, Criteria etc que debemos incluir aca?