javax.inject.*

[Paul Hammant-3]

http://google-code-updates.blogspot.com/2009/05/javaxinjectinject.html

Last summer Bob, Rod and I met for a lunch to discuss potential for  
commonality, for the DI frameworks that we represent.  We came away  
with more questions than answers.  Since then things move on of  
course, and we* see that Seam is trying to introduce a DI  
specification, and the Guice has made popular the form of DI that  
PicoContainer started many years ago, its Provider<T> style proves  
popular too.  Annotated DI has been introduced by EJB 3.0 (and got  
wrong) and Guice made it better.  All of Spring, Pico and Guice are  
now using annotations, and maybe its smart to settle on a single spec  
for that, to allow component interop.  Also on the table with this JSR  
(and immensely important to me in particular) is the principle of  
Lowest Common Denominator.  For example, Spring folks may suggest that  
XML meta-data is still the correct way to do DI, but the spec leaves  
that open to the container makers and does not force it on the  
component coders.

So we're still going to support components with no annotations, as we  
always did, but it seems smart to settle on this spec's annotations  
for situations where the component coder prefers it.

* I don't know about Bob or Rod, but Seam's attempt to own injection  
at the javax level leaves me with the 'heebie jeebies'.  I'm still  
remembering all the "bi-jection" stuff from a few years ago.

Regards,

- Paul


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[mihobson]

2009/5/5 Paul Hammant <paul@...>:

> http://google-code-updates.blogspot.com/2009/05/javaxinjectinject.html
>
> Last summer Bob, Rod and I met for a lunch to discuss potential for
> commonality, for the DI frameworks that we represent.  We came away with
> more questions than answers.  Since then things move on of course, and we*
> see that Seam is trying to introduce a DI specification, and the Guice has
> made popular the form of DI that PicoContainer started many years ago, its
> Provider<T> style proves popular too.  Annotated DI has been introduced by
> EJB 3.0 (and got wrong) and Guice made it better.  All of Spring, Pico and
> Guice are now using annotations, and maybe its smart to settle on a single
> spec for that, to allow component interop.  Also on the table with this JSR
> (and immensely important to me in particular) is the principle of Lowest
> Common Denominator.  For example, Spring folks may suggest that XML
> meta-data is still the correct way to do DI, but the spec leaves that open
> to the container makers and does not force it on the component coders.
>
> So we're still going to support components with no annotations, as we always
> did, but it seems smart to settle on this spec's annotations for situations
> where the component coder prefers it.

Good to see progress on standardising annotations for DI, even if
JSR-299 doesn't want to play.

What concerns me is the trend of annotating components with IoC
configuration.  Surely this is not particularly IoC?  Why enforce
clients to use a specific constructor with @Inject when convention
(most satisfiable) or container configuration could be used?  Why
annotate setters with @Inject when it's pretty obvious that they can
be set?  Why resolve ambiguous dependencies *within* the component
using qualifier annotations when it's surely the client's
responsibility to decide?

On one hand we're inverting control of dependencies to the component's
client, and then on the other we're hardcoding component configuration
within itself.  I appreciate that Pico will continue to support
components without annotations, but I was wondering if this topic had
come up when chatting with the Guice/Spring guys?  It'd be good to see
a standard API emerge for configuring a container, although I guess
this is still volatile ground at the moment.

Mark

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Paul Hammant-3]

>
> Good to see progress on standardising annotations for DI, even if
> JSR-299 doesn't want to play.
>
> What concerns me is the trend of annotating components with IoC
> configuration.  Surely this is not particularly IoC?  Why enforce
> clients to use a specific constructor with @Inject when convention
> (most satisfiable) or container configuration could be used?

Agree.

> Why
> annotate setters with @Inject when it's pretty obvious that they can
> be set?  Why resolve ambiguous dependencies *within* the component
> using qualifier annotations when it's surely the client's
> responsibility to decide?
>
> On one hand we're inverting control of dependencies to the component's
> client, and then on the other we're hardcoding component configuration
> within itself.  I appreciate that Pico will continue to support
> components without annotations, but I was wondering if this topic had
> come up when chatting with the Guice/Spring guys?

Bob Lee, Kevin Bruillion, Jesse Wilson (Guice folks) and Rod Johnson  
(Mr Spring) will all report that I've positively advocated Pico's more  
advanced features to them on and off over the years, encouraging them  
to implement the same (mostly transparent) features.

> It'd be good to see
> a standard API emerge for configuring a container, although I guess
> this is still volatile ground at the moment.

It is.  This JSR good. There was going to be a possibility that  
everyone would have to support everyone else's @Inject annotation, but  
that's gone now.  The JSR 299 initiative has no authority, it not  
being from the DI community.  Previous Gavin King had touted "Bi-
jection" as much-better than Dependency Injection.  In fact there was  
a time in 05/06 when he came to a ThoughtWorks away day in Chicago and  
presented on Seam and it's (then) leverage of Bi-jection.

Regards,

- Paul

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[mihobson]

2009/5/14 Paul Hammant <paul@...>:
> Bob Lee, Kevin Bruillion, Jesse Wilson (Guice folks) and Rod Johnson (Mr
> Spring) will all report that I've positively advocated Pico's more advanced
> features to them on and off over the years, encouraging them to implement
> the same (mostly transparent) features.

Glad to hear that I'm not alone here.  I remember having a brief chat
with Bob & Kevin at JavaOne last year and they couldn't seem my
problem with annotations.  Fortunately Pico still occupies that
sweet-spot between Spring XML and Guice annotations.

> It is.  This JSR good. There was going to be a possibility that everyone
> would have to support everyone else's @Inject annotation, but that's gone
> now.  The JSR 299 initiative has no authority, it not being from the DI
> community.  Previous Gavin King had touted "Bi-jection" as much-better than
> Dependency Injection.  In fact there was a time in 05/06 when he came to a
> ThoughtWorks away day in Chicago and presented on Seam and it's (then)
> leverage of Bi-jection.

Yes, JSR-299 certainly appears hostile towards standardising @Inject.
Good to see that you guys can still collaborate for a more
interoperable future.

Cheers,

Mark

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email