Veio hoje o email para o grupo, indicando que o Early Draft Review da nova especificação de persistência do Java está disponível para o público olhar e, claro, opinar.
É bem verdade que ela veio com o atraso de um mês (a previsão desse review era para o Abril passado), mas veio em boa hora igual.
Números e Improvements
Tenho inclinação inconsciente (olha eu usando palavras seguidas com as mesmas iniciais) para olhar as coisas e traçar comparativos. Essa JSR tem 299 páginas, que equivale ao número da JSR dos WebBeans, que está nas mão do hábil Gavin King.
Coincidências à parte, essa nova versão da Java Persistence API busca expandir os recursos da JPA 1.0, agregando features que há muito já deveriam estar disponíveis: melhorias na linguagem de query; expansões no mapeamento objeto-relacional (com ênfase para listas ordenadas, coleções de objetos embutidos e alguns outros recursos relacionados); padronização na engine de geração da DDL; contratos expandíveis para passivação e replicação de contextos de persistência; melhorias e uma maior padronização no gerenciamento nos estados dos entity beans e, principalmente, o suporte a validação dos beans.
Quanto à API Criteria (que diga-se de passagem, eu não gosto), esse primeiro draft nao trouxe nada de novo. Acredito que o grupo ainda não chegou a um denominador comum e, por isso, acho que esse capítulo somente deve vir no draft 2 desse documento.
Contraste
Não conheço niguém que usa JPA puro. Em outras palavras, não conheço ninguém que efetivamente homologou sua aplicação JPA com múltiplos frameworks sobre múltiplos banco de dados em múltiplos servidores.
Acredito eu - até que me provem o contrário - que isso é utopia mesmo. Ninguém em sã consciência (diga-se de passagem, os stakeholders) está a fim de arcar com isso, mesmo porque o ROI (Return Of Investment) de um trabalho desses sempre tende a zero.
Assim, o que acontece é que as pessoas (como eu) acabam usando implementações robustas (como o Hibernate - desculpem, mas Toplink não é um exemplo aqui) e deixam a equidade do JPA de lado.
Nesse sentido, essa revisão na JPA é mais impactante para os players que criam as implementações, e não nós que as utilizamos.
Ainda sem cache
Já era esperado, mas repito que eu ficaria feliz se o recuso de cache fosse disponibilizado na JPA.
Quem usa Hibernate, tem isso desde suas primeiras versões; antes com o ehcache, e hoje com o maravilhoso suporte dos caches clusterizados hierárquicos do JBoss :). Porém, essa feature ainda não deve vir tão cedo.
Ao meu ver, o recurso de cache na JPA somente deve vir lá pela versao 4 ou mais. Isso ocorre porque para termos um recurso de cache consistente, dependemos de protocolos de mais baixo nível, os quais estao na infra-estrutura de base do servidor EJB, tais como replicação e failover, lembrando que isso pode incluir recursos clusterizados ou não em ambientes transacionais e em modelos de rede muito atipicos. Quem usa JBoss se aproxima disso; quem usa outros servidores de aplicação, eu não tenho tanta certeza.
Obviamente, o recurso de cache poderia comerçar simplório (hic), como foi o ehcache lá nos idos do Hibernate 1.0 (há mais de 5 anos). Porém, acredito que isso esta mais para uma outra JSR, visto que envolveria mais do que apenas os entity beans. Enfim, ainda não temos.
Mais detalhes! Mais detalhes!
Vou ter que ler a especificação para saber exatamente o que mudou frente à JSR 220 (há, eu gostava tanto desse número). Somente depois, vou poder dar mais detalhes.
Sugiro para quem trabalhe na área, que baixe os 5MB do PDF e leia também. Afinal, a leitura é uma constante na nossa área.
Quanto ao release de hoje, bem, é o mundo evoluindo :)
É bem verdade que ela veio com o atraso de um mês (a previsão desse review era para o Abril passado), mas veio em boa hora igual.
Números e Improvements
Tenho inclinação inconsciente (olha eu usando palavras seguidas com as mesmas iniciais) para olhar as coisas e traçar comparativos. Essa JSR tem 299 páginas, que equivale ao número da JSR dos WebBeans, que está nas mão do hábil Gavin King.
Coincidências à parte, essa nova versão da Java Persistence API busca expandir os recursos da JPA 1.0, agregando features que há muito já deveriam estar disponíveis: melhorias na linguagem de query; expansões no mapeamento objeto-relacional (com ênfase para listas ordenadas, coleções de objetos embutidos e alguns outros recursos relacionados); padronização na engine de geração da DDL; contratos expandíveis para passivação e replicação de contextos de persistência; melhorias e uma maior padronização no gerenciamento nos estados dos entity beans e, principalmente, o suporte a validação dos beans.
Quanto à API Criteria (que diga-se de passagem, eu não gosto), esse primeiro draft nao trouxe nada de novo. Acredito que o grupo ainda não chegou a um denominador comum e, por isso, acho que esse capítulo somente deve vir no draft 2 desse documento.
Contraste
Não conheço niguém que usa JPA puro. Em outras palavras, não conheço ninguém que efetivamente homologou sua aplicação JPA com múltiplos frameworks sobre múltiplos banco de dados em múltiplos servidores.
Acredito eu - até que me provem o contrário - que isso é utopia mesmo. Ninguém em sã consciência (diga-se de passagem, os stakeholders) está a fim de arcar com isso, mesmo porque o ROI (Return Of Investment) de um trabalho desses sempre tende a zero.
Assim, o que acontece é que as pessoas (como eu) acabam usando implementações robustas (como o Hibernate - desculpem, mas Toplink não é um exemplo aqui) e deixam a equidade do JPA de lado.
Nesse sentido, essa revisão na JPA é mais impactante para os players que criam as implementações, e não nós que as utilizamos.
Ainda sem cache
Já era esperado, mas repito que eu ficaria feliz se o recuso de cache fosse disponibilizado na JPA.
Quem usa Hibernate, tem isso desde suas primeiras versões; antes com o ehcache, e hoje com o maravilhoso suporte dos caches clusterizados hierárquicos do JBoss :). Porém, essa feature ainda não deve vir tão cedo.
Ao meu ver, o recurso de cache na JPA somente deve vir lá pela versao 4 ou mais. Isso ocorre porque para termos um recurso de cache consistente, dependemos de protocolos de mais baixo nível, os quais estao na infra-estrutura de base do servidor EJB, tais como replicação e failover, lembrando que isso pode incluir recursos clusterizados ou não em ambientes transacionais e em modelos de rede muito atipicos. Quem usa JBoss se aproxima disso; quem usa outros servidores de aplicação, eu não tenho tanta certeza.
Obviamente, o recurso de cache poderia comerçar simplório (hic), como foi o ehcache lá nos idos do Hibernate 1.0 (há mais de 5 anos). Porém, acredito que isso esta mais para uma outra JSR, visto que envolveria mais do que apenas os entity beans. Enfim, ainda não temos.
Mais detalhes! Mais detalhes!
Vou ter que ler a especificação para saber exatamente o que mudou frente à JSR 220 (há, eu gostava tanto desse número). Somente depois, vou poder dar mais detalhes.
Sugiro para quem trabalhe na área, que baixe os 5MB do PDF e leia também. Afinal, a leitura é uma constante na nossa área.
Quanto ao release de hoje, bem, é o mundo evoluindo :)
0 comentários:
Postar um comentário