Criteria na JPA 2.0: Public Review!

{ December 11th, 2008 }

Autor: cmilfont

Na “Public Review” da JSR317 - que trata da JPA 2.0 - foi adicionado suporte a Criteria API na especificação. Pode ser que em menos de dois anos possamos evoluir nessa especificação e usar menos as implementações, minha esperança é que melhorem pelo menos até a versão final, programada para o início de 2009.

Como sempre criaram uma nomenclatura totalmente diferente para entidades da API, dificultando o entendimento da comunidade com anos de uso da única implementação que possuía essa API: Hibernate. Comparem a API de Criteria do Hibernate com a API de Criteria da Spec. Ok, podemos aceitar isso, política…

Faltou muita coisa ainda, mas parece que estão trabalhando para melhorar até a versão final, pelo visto DELETE_ORPHAN vai sair de alguma forma:

@Target({METHOD, FIELD}) @Retention(RUNTIME)
public @interface OneToMany {
    Class targetEntity() default void.class;
    CascadeType[] cascade() default {};
    FetchType fetch() default LAZY;
    String mappedBy() default "";   
    boolean orphanRemoval() default false;
}

Nota para os leitores:

Open Issue: We also discussed the alternative of introducing a separate annotation for the orphanRemoval functionality and the alternative of introducing a REMOVE_ORPHAN cascade
option. We would welcome feedback on the form that this metadata should take.

Não encontrei nada sobre como manipular as estratégias de fetching - que é primordial - nos relacionamentos como temos no Hibernate: Select fetching, Subselect fetching, Join fetching e Batch fetching. Nem a API de Criteria possui estratégia com FetchMode, apenas uma “Issue” aberta para a interface FetchJoinObject que deverá trabalhar isso, eu espero.

Ainda assim continuamos indicando o uso do Hibernate direto ao invés da especificação até que a especificação seja estável o suficiente com features decentes para um desenvolvimento sério em Java. A API de Criteria da implementação Hibernate continua ainda muito superior principalmente se você precisar de consultas um pouco mais avançadas.

Confiram o material e decidam.

Posted in Engenharia de Software, Linguagens, Orientação a Objetos ~ 2 Comments

SCEA com design patterns errados

{ October 28th, 2008 }

Autor: cmilfont

Once upon a time…

… A comunidade em volta da JCP adotou a aberração proposta pela SUN chamada EJB e o mecanismo de persistência seria uma JSR especialista chamada JDO. JDO seria a solução deifnitiva onde não importaria se você usa um txt, um xml ou um Banco de dados parrudo.

Com esse modelo de desenvolvimento foi criado um catálogo de Design Patterns[?] que serviria de “tábua dos 10 mandamentos” para a comunidade. Nasceu a prova de certificação em Arquiteto java com base nessa arquitetura.

Por fora da JCP uma turma se dedicou a criar uma forma de persistência específica para bancos de dados relacionais [Hibernate] onde não estavam preocupados se você guardava seus dados em um xml, queriam apenas resolver os problemas clássicos do mapeamento objeto-relacional. Outro pessoal jogava fora o modelo EJB e criava sua própria JEE [Spring] com técnicas e abordagens que surgiam como IoC, DI, Aspect Programming.

Com esse modelo de desenvolvimento, baseado sobretudo no conjunto de Design Patterns [PoEAA] da turma do Fowler, aposentaram o modelo da SUN apreciado pelos membros da JCP e redirecionaram o comitê para a aprovação de especificações copiadas desse outro modelo.

… and they lived happily ever after.

…

Opa, faltaram atualizar a prova de Arquiteto Enterprisey para adequar aos Patterns corretos. Ainda leio na ementa da prova no capítulo sobre Patterns:

• From a list, select the most appropriate pattern for a given scenario. Patterns are limited to those documented in the book - Alur, Crupi and Malks (2003). Core J2EE Patterns: Best Practices and Design Strategies 2nd Edition and named using the names given in that book.
• From a list, select the most appropriate pattern for a given scenario. Patterns are limited to those documented in the book - Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides (1995). Design Patterns: Elements of Reusable Object-Oriented Software and are named using the names given in that book.
• From a list, select the benefits and drawbacks of a pattern drawn from the book - Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides (1995). Design Patterns: Elements of Reusable Object-Oriented Software.
• From a list, select the benefits and drawbacks of a specified Core J2EE pattern drawn from the book – Alur, Crupi and Malks (2003). Core J2EE Patterns: Best Practices and Design Strategies 2nd Edition.

Posted in Certificações, Design Patterns, Engenharia de Software, JSE, Java, Melhores práticas ~ 6 Comments

Especificação ou implementação?

{ October 27th, 2008 }

Autor: cmilfont

A primeira recomendação em qualquer ramo é sempre seguir a especificação, isso é válido para não cairmos em um dos piores anti-patterns que existe, o “Vendor Lock-in“. Na indústria do Software passamos por isso frequentemente e a estratégia de Embrace-Extend-Extinguish esteve bastante presente na história dos bancos de dados como exemplo disso.

Features proprietárias são sedutoras, antigamente usávamos grids com paginação no HTML com a propriedade datasrc na tag table, podíamos ler inclusive de arquivos XML. Isso muito antes de Ajax ou até do Firefox. Evidente que só funcionava no IE.

<XML ID="users">
<?xml version="1.0" ?>
<users>
	<user id="1" name="Christiano Milfont"/>
	<user id="2" name="Rafael Ponte"/>
</users>
</XML>
 
<TABLE DATASRC="#users">
<TR>
<TD><DIV DATAFLD="id"></DIV></TD>
<TD><DIV DATAFLD="name"></DIV></TD>
</TR>
</TABLE>

Com a popularização do Firefox e a necessidade das aplicações serem CrossBrowser, tivemos que nos adaptar às specs da W3C. Praticamente todas as aplicações WEB precisaram serem reescritas -algumas até hoje ainda só “rodam” no IE.

Usar uma Feature proprietária facilita, mas no final você pagará o preço da não interoperabilidade. Agora precisamos usar um Framework Ajax para fazermos coisas que antes era nativo. No IE tínhamos até DnD.

Especificação muito mais frágil do que as implementações nos força a criar uma “Isolation Layer” como solução de refactoring sem comprometer o sistema. Podemos então usar as features nos beneficiando do que a implementação tem a oferecer sem comprometermos o resultado final, o uso fica encapsulado na solução.

Especificação mal feita

O problema é quando a definição de uma especificação fica frágil o suficiente - por problemas políticos - para forçar um refactoring profundo na mudança entre implementações.

No CEJUG, ocorreu uma thread sobre problema com data na JPA, onde eu recomendei retirar a anotação @Temporal - que já tinha me dado trabalho anteriormente - e por “feeling” eu sabia que o problema era nessa anotação, mas nunca tinha pesquisado para saber o real porquê. Como quem ganhou dinheiro com Feeling no Brasil foi apenas Morris Albert - by Cardoso - eu dei uma pesquisada sobre isso e descobri que [como escrevei no email]:

From CMilfont
to discussao@cejug.dev.java.net
date Mon, Oct 27, 2008 at 9:54 AM
subject Re: [cejug-discussao] problema com data

Dei uma pesquisada e a conclusão que cheguei é:
A spec determina que propriedades do tipo Date e Calendar [util java] devem ter a anotação @Temporal.
TopLink obriga, se não tiver lança uma exceção ValidationException [pelo menos foi o que vi na documentação dele, não cheguei a testar].
Hibernate é opcional, mas se você colocar ele devolve uma instância de Calendar, porque entende que a data é completa [como Timestamp] mesmo dizendo que o tipo é Date - aqui entendo como uma falha e vi que as issues sobre isso no projeto já foram fechadas, os últimos builds devem ter consertado, ou não.
A spec não diz que deve lançar exception mesmo dizendo “must be” então o Oracle TopLink assumiu essa responsabilidade.
Claro que essas funcionalidades devem também mudar de build para build então podem ter diferenças nas versões de builds entre os próprios implementadores, como Hibernate e TopLink mudarem da versão x.x.1 para x.x.3 por exemplo.
Coisas de spec mal escrita, JPA tem que ser urgente revista, os capítulos ficam muito ambiguos, tem trechos que você fica bastante confuso, diferente de specs como da JSE que é bastante clara.

O problema disso é que não dá para encapsular a diferença entre as implementações porque o uso dessa anotação é incompatível entre dois desses implementadores.

Outro problema da JPA é a falta de elementos básicos que um ORM deve implementar - como a Criteria - impossibilitando a troca de implementações com um simples refactoring. Tudo bem que em um Domain Model você tem como - e deve - isolar essa diferença entre Engines ORM mas em termos de Refactoring da aplicação no geral, ter que reescrever todas as buscas de uma aplicação porque a Engine não suporta Criteria pode não afetar o modelo mais trará um prejuízo enorme.

Como o Hibernate é OpenSource, maduro e anos-luz à frente até da nova especificação de JPA 2.0, a escolha dele pelos profissionais experientes é a mais adequada. Spring, é outra solução ao JEE sem EJB que permanece como indicação desde o livro do Rod Johson de 2004 que era ainda sobre EJB2, recomendava o uso de JEE sem EJB e apresentou o Spring oficialmente ao mundo. Apesar de que Spring e EJB3 estarem bem nivelados hoje em dia, Spring ainda leva uma certa vantagem, ainda mais pela maturidade e semrpe estar nos trilhos corretos, coisa que o EJB está se ajustando aos trancos e barrancos.

Em regra eu sempre recomendo o uso de especificações, mas em determinados pontos a especificação é desaconselhada e o uso direto da implementação tem suporte mais adequado. Não temos o poder de sempre escolhermos as ferramentas mais adequadas, muitas vezes a política impera - como nos órgãos públicos que são obrigados a usarem Oracle ou IBM por imposição governamental feita em um escritório na Casa Civil.

Posted in Engenharia de Software, JEE, Java, Linguagens, Melhores práticas, Orientação a Objetos, Software Livre ~ 6 Comments