Aleluia irmaos, finalmente a JSR 330

Acho que esta foi uma das mais rápidas movimentações do grupo JCP, onde conseguimos em um período de apenas 14 dias ter uma aprovação unânime sobre o assunto.

E qual o assunto mesmo? Injeção de dependências no Java ou, mais precisamente, a JSR 330.

Os Bandeirantes

Aos que se recordam, acho que a coisa começou la nos idos dos XDoclets (lembram?) com frameworks de Byetecode Enhancement (como o CGLib e o agora facílimo Javassist).

Depois veio as anotações Java e integrações com XML (já falei que detesto eles?) e frameworks AOP para, enfim, aparecer a IoC.

Águas passadas, tempo passou. E então vários e vários produtos surgiram, cada qual trazendo uma promessa milagrosa mas que, de alguma forma, trouxeram paulatinamente benefícios no nosso (belo e gordo) stack operacional.

Guice e Springframekork

Enquanto eu adoro o estilo do Google Guice, a galera do Springframework berra sempre aos quatro lados que foram eles que inventaram essa coisa de Inversão de Controle (IoC) e toda essa tralha de "programar por fora" do sistema.

Não que eu discorde, pelo contrário. Realmente acho IoC uma coisa muito útil e vital em sistemas enteprise. Mas falar que foram eles, bem, nosso amigo B. Meyer não ficaria tão feliz assim com uma declaração dessas...

Enfim, espero que a abordagem do branquelo para injeção de dependências balize esta JSR e que o pessoal do Springframework possa contribuir com seus anos de experiência (e dores) para criar arquiteturas flexíveis, extensíveis e, principalmente, estáveis.

Sim meninos, se vocês "perderam" na Umbrella JSR 313, agora vocês têm a sua rendenção à vista. Mas não desperdicem...

Os Votos e os Comentários

Dos 16 votantes, a Red Hat e a Nortel se absteram. O resto votou (de forma quase singela) Sim.

Embora a abstinência da Nortel não me interessa muito, a posição da vermelhona eu não entendo muito bem.

Argumentaram que IoC causa dependência de um container externo (o injetor de recursos) e coisas do gênero (...). Não sei quem da vermelhona que votou, mas o cara devia tá com outra dor de barriga no moemento pra dizer isso, uma vez que, para este argumento, não existe respaldo: é óbvio que isso á balela: O Guice é o que então?!

Os outros votaram e colocaram alguns comentários, com sempre.

A Sun pediu para a galera do Guice e Spring puxarem as rédeas das especificacação. E isso é bom (espero).

O pessoal do Spring votou e, pasmem, sem mais ressalvas.

A Ericsson enfatizou que o pessoal da JSR 299 deve estar sempre próximo desse grupo para não criarem duas "coisas" paralelas ao invés de convergentes. Concordo com eles.

A IBM e a Oracle foram na mesma linha, ou seja, dizendo que é importante evitar paralelismo.

Amém.

Afinal, JSR?

É óbvio que a 299 e essa 330 se sobrepõe em alguns pontos. Porém, o problema não é esse, e sim o tempo.

É notória a (r)evolução que as arquiteturas enterprise galopam, enquanto as SE's arrastam. inda hoje não tempos uma alternativa ao Swing!

Assim, se a 299 surgiu antes, vamos correr atrás do prejuízo e definir uma para o mundo SE e depois, durante sua construção, fazer a convergência.

O que não podemos fazer é estender ainda mais a 299 ou outras (JSRs) enterprises para cobrir o mundo todo. A 318 e suas quase 650 páginas que o digam.

Temos que repensar no trabalho do JCP, isso sim.

Afinal, gigantes ou não, quem está no Comitê deve definir padrões, e deixar suas brigas mercadológias no mundo pontoCom.

Farpas à parte, temos uma nova JSR.