A Maldita Anotação @LocalBean

Há pouco mais de um ano, eu estava postando sobre as novidades do EJB 3.1 - nossa, como o tempo passa! - e falava que a idéia do Bill (Burke) parecia que não iria vingar. Mas vingou.

Como todos já sabem (?), no Java EE 6 teremos o suporte à publicação local de EJBs, os quais poderão ser simples classes POJOs que não implementam nenhuma interface e que sejam anotadas com pouco mais do que @Stateless (@Stateful).

Isso seria muito legal, nao fosse o "pouco mais", conforme a página 84 (seção 4.4.2.2) da PFD (Proposed Final Draft) da JSR 318, que fala da maldita anotação @LocalBean.

A (Maldita) Anotação @LocalBean

Essa anotação não existia até agora, e é necessária para avisar o Container Java EE que o POJO em questão está sim publicando um EJB para acesso local.

Segundo a especificação isso é necessário porque podem existir EJBs que não desejam publicar um acesso local à sua funcionalidade de negócio e, situação que poderia incorrer em comportamentos anômolos durante o uso da aplicação...

Para mim isso soa como aquelas malditas e antiquadas interfaces LocalHome, RemoteHome e outras da série EJB 2.x, e em nada isso me sinaliza uma solução elegante para o problema.

Talvez minha mente obtusa não consiga enxergar muito longe e por isso eu esteja errado. Mas o é fato que colocar mais esta anotação incha ainda mais a especificação (copiando as palavras de Rod Johnson) e implica que EJBs pré-existentes tenham que ser, no mínímo, recompilados para funcionar (talvez até não, mas com certeza um re-empacotamento com descritores XML sobreescrevendo alguns comportamentos, isso sim).

O Bugs que Funcionavam

Quem acompanhou a Issue 751 e outras do JBossAS, sabia que na versão 4.0.5 era perfeitamente possível (e perfeitamente "funcionável") termos um EJB (ou uma interface) anotado com @Local e @Remote ao mesmo tempo.

Na versão 4.2 isso foi "corrigido" para, justamente (como dizia o Juvenal), aderir à especificação. Para mim, isso foi um caos - simplesmente tive que refazer vários dos meus EJBs nos processos de migração.

Ruby on Rails, Grails (e Outros da Série Convention Over Configuration)

Frameworks novos usam muito bem a prática da convenção ao invés da configuração. No mundo EJB (e Java EE), eu adoraria ver isso em prática.

Sim, demos um passo com a padronização (ainda rudimentar) do JNDI para os containers, porém precisaríamos caminhar mais rápido nesse cenário.

Anotações como @Stateless ou @Stateful são muito legais, mas poderiam simplesmente não existir, idem. E também poderíamos ter que nunca conhecer uma @LocalBean e nem mesmo se preocupar no projeto do sistema se vamos usar @Remote ou @Local sobre nossos elementos.

Com o andar da carruagem, simples modificações no container de IOC poderiam fazer todo esse mexe a qualquer momento, não exigindo a definição a priori, do comportamento de nossos beans no servidor de aplicação.

A (Longa) Estrada da Vida

A conversa poderia seguir indefinidamente, ao ponto de realmente modelarmos sistemas complexos segundo os princípios DDD, sem se preocupar com aspectos verticais no Stack (transações, contextos, clusters, local, remoto, etc, etc, etc). Em suma, um "mundo POJO" seria simplesmente lindo.

E isso não é utopia. Já podemos fazer muito disso com frameworks atuais e com o suporte a linguagens dinâmicas na Java 7, as coisas podem ir muito além. Muito além mesmo!

O "brabo" é fazer as pessoas pararem de pensar em novas e lindas Annotations.