A JSR 330, formada principalmente pelo pessoal do Spring e do Guice, foi aprovada para entrar em desenvolvimento: http://jcp.org/en/jsr/detail?id=330
Existe uma preocupação grande dos participantes em mante-la alinhada com a JSR 299 (Web Beans) para que esforços não sejam repetidos http://jcp.org/en/jsr/results?id=4944
É um grande passo para o Spring e para o Guice, procurando vir a ser uma especificação, em especial por já serem consagrados containers de IOC com DI. A entrada diretamente no Java SE é um fato importante e que facilitará a adoção.
hehehe, mais um pacote javax.inject ou java.inject
acredito que boa parte será advindo das mesmas características do Spring Dependecy Annotation
acho que a motivação demorou para acontecer, e já estava na hora, conforme complementa breve descrição do trecho retirado da JSR, respondendo a pergunta: 2.7 Please give a short description of the underlying technology or technologies?
ao invés de termosclass Stopwatch {
final TimeSource timeSource;
Stopwatch () {
timeSource = DefaultTimeSource.getInstance();
}
void start() { ... }
long stop() { ... }
}poderemos fazer
class Stopwatch {
final TimeSource timeSource;
@Inject Stopwatch(TimeSource TimeSource) {
this.TimeSource = TimeSource;
}
void start() { ... }
long stop() { ... }
}
a princípio não parece ser grande avanço, mas caracterizará menor esforço e maior plugabilidade a partir das formas tradicionais com factories e outros como o padrão service locator, em que agora já não fará sentido nenhum utilizá-lo, em que na verdade já não fazia, mas menciono isto mais ao uso puro do Java SE
foi unanime com 14 votos a favor, bom trabalho para rod johson e bob lee
acho que até final de outubro teremos uma revisão final do expert group, se até lá não tiverem muitas mudanças como houve com a JSR 299
É só olhar mais atentamente a movimentação do JCP para perceber que as propostas atendem mais aos interesses das “vendors” do que necessariamente da comunidade Java. A JSR-299 (WebBeans) é mais interessante para a Red Hat, pois: 1) implica que seu framework web (Seam) pode ser rodado em qualquer container web Java EE 6 sem parto; 2) joga pra escanteio outros frameworks de injeção de dependência que existem por aí, inclusive o do Spring Source, seu concorrente.
Quando tudo tava certo que a Red Hat ia papar uma especificação prontinha pros seus interesses, surge essa nova JSR-330, que trás à tona os outros containers de DI “rejeitados”, e força a especificação JSR-299 a se adequar à 330, sob pena de não ser aprovada. Parabéns Red Hat, mereceu.
Eu acho interessante essa nova especificação, injeção de dependência é realizado, de um jeito ou de outro, por dezenas de frameworks. Até um, como o VRaptor, poderia usar essas novas anotações.
pois é, eu estava curioso quanto a especificação para OSGI, mas quando fui ver a JSR 277 está inativa, alguém sabe o porquê ?
será que a JSR é esta mesma ou se migraram para alguma outra ?
[quote=faelcavalcanti]pois é, eu estava curioso quanto a especificação para OSGI, mas quando fui ver a JSR 277 está inativa, alguém sabe o porquê ?
será que a JSR é esta mesma ou se migraram para alguma outra ?[/quote] Project Jigsaw.
Mas até onde eu sei o OSGi não fazia parte de nenhuma JSR.
Pelo contrário…o próprio Peter Kriens reclama da falta de abertura do JCP.
Se bem que nesse novo projeto Jigsaw eles falam em “conversar mais” com pessoal da OSGi foudation.
