Introduzida a 2 anos atrás como parte do Java EE 5, o Java Persistence API fornece um modelo POJO de persistência para mapeamente Objeto Relacional. Ele foi desenvolvido pelo EJB 3.0 Expert Group como parte da JSR-220.
A persistência consiste de 3 áreas:
- A API, definida no pacote javax.persistence.
- O Java Persistence Query Language (JPQL).
- Metadados Object/relational.
Apesar da JPQL ter melhorado com objetos Java persistentes, as queries JPQL ainda são especificadas com strings. Entõa, apesar das queries operarem sobre objetos JAva fortemente tipados, elas ainda são fracamente tipadas. Construir queries desta forma pode favorecer o erro e requer suporte de IDEs para validação, auto completion e refactoring.
JPA 2.0, que está sendo desenvolvido sob a JSR-317 para inclusão no Java EE 6, almeja resolver isso através da introdução de uma nova API de criteria que oferece uma abordagem não baseada em string para construir queries. O líder do Expert Group Linda DeMichel publicou um post descrevendo o rascunho atual da API:
"Basicamente falando, um objeto QueryDefinition pode ser visto como um conjunto de nós correspondentes a construções semanticas da query:
- Domain objects, que correspondem ao range de variáveis e outras variáveis de identificação da cláusula FROM do JPQL
- Predicados de cláusula Where, que compreendem um ou mais objetos de expressões condicionais
- Cláusula Select , que compreendem um ou mais objetos "select item"
- Itens Order-by e group-by
- Subqueries
e assim por diante..."
Mesmo a proposta representando um bom avanço em relação ao mecanismo JPA existente, várias pessoas, dentre elas Gavin King, tem argumentado que segurança de tipo pode e deve ser melhorado. King, cuja ferramenta Hibernate O/R está entre as pioneiras no uso de criteria type-safe e uma grande influência no EJB3, submeteu sua própria proposta para o Expert Group. Sua proposta explora o javax.annotation.Processor introduzido no Java 6 para permitir um plugin de compilador construir um tipo metamodel para cada classe persistente na aplicação. King escreveu dois posts (um, dois) que descrevem sua abordagem em mais detalhes e ele e seu time estão atualmente trabalhando num protótipo de processador de annotation para uso com o javac.
O Expert Group está olhando a proposta do King seriamente e está considerando-a como substituta para o draft atual. DeMichiel nos disse:
"A discussão tem focado em certificar-se que essa API leve a uma melhor experiência para os desenvolvedores, tanto para queries estáticas (onde os aspectos type-safe devem brilhar) e para queries dinâmicas. Nós também olhamos para os aspectos de geração de metamodel."
Ela acrescentou que o Expert Group é muito aberto a qualquer feedback da comunidade de desenvolvimento. Por favor, envie seus comentários para a jsr-317-pdr-feedback no sun dot com.