Consultas con “tipado fuerte” en JPA 2.0

Hace poco en JavaHispano se publicó una noticia sobre LIQUidFORM, para realizar consultas en JPA sin depender de cadenas que no pueden comprobarse en tiempo de compilación. Las ventajas de este tipo de soluciones son incuestionables, ya que permiten que el compilador nos pueda decir si nos estamos equivocando y además abren la puerta al auto-completado, refactoring y demás herramientas que desde un buen IDE nos pueden facilitar mucho la vida.

Se ve el grupo que define la especificación JPA no le son ajenos estos conceptos y están pensando en introducir un nuevo API, “Criteria”, para hacer cosas parecidas. Podéis ver una presentación en una entrad del blog de la líder del grupo Linda DeMichiel: Java Persistence 2.0 Public Draft: Criteria API.

 Personalmente creo que es una buena idea, aunque algunas cosas de la propuesta no me gustan demasiado, y dado que para eso estamos en comunidad hice llegar mi opinión. El problema principal para mí es que la propuesta depende mucho del uso de literales en forma de cadenas, que no pueden ser verificados en compilación, ni auto-completados, renombrados... Pero a ese mensaje me contestó Gaving King, el cual forma parte también del grupo y que teniendo en cuenta el “feedback” de la comunidad, ha pensado una alternativa la cual permitiría no tener literales en tu propio código, haberlos los hay pero los genera automáticamente el compilador, y además evita los problemas de las soluciones del tipo LIQUidFORM, que se basan en los getters/setters de los campos, los cuales no son imprescindibles en JPA y además abren la puerta a problemas con campos calculados que tengan su propio método get. Podéis ver su propuesta final en este mensaje: Java 6 compiler plugins and typesafe criteria queries

Así que esta noticia es por un lado para que conozcáis lo que se está cociendo, animaros a dar vuestra opinión que para eso está el JCP y la comunidad Java. Con la ayuda de todos es como conseguiremos mejorar las cosas antes de que ocurran, en vez de quejarnos de los cambios “a posteriori”.