@Inject annotation

[Anthony MULLER]

Hello,

I have a little request about next release of Guice. Currently, we have to use @Inject into the code to say that we want Guice "inject here".

My concern is we have "import com.google.inject.Inject;" into the class... It is not really 'my' concern but some guys find it is intrusive...

So, my proposal is to indicate to Guice the annotation class to use : Guice.setInjectAnnotationType(my.package.MyInject.class);

So, Guice looks now for MyInject annotation (instead of standard Inject one) and I don't have the com.google.inject.Inject import in my class...

What do you think about this?

Regards,
Anthony

[Stuart McCulloch]

2008/12/12 Anthony MULLER <anthony...@gmail.com>

this has been discussed on the list many, many times ;)  it would definitely make things more flexible, but people have raised concerns, like it could confuse people new to your code (how do they know that @Wibble actually marks an injection point?)

FYI, these are the two longest threads from last year that cover most viewpoints:

   http://groups.google.com/group/google-guice/browse_thread/thread/28f565a532ce249c
   http://groups.google.com/group/google-guice/browse_thread/thread/ba2238025cde1604

and you might want to check out James Strachan's patch to support custom annotations:

   http://macstrac.blogspot.com/2008/10/adding-support-for-postconstruct.html

there is also an open issue tracking the original feature request:

   http://code.google.com/p/google-guice/issues/detail?id=70

however, perhaps this is best left until after the next release - rather than attempt to rush something in at this point...

Regards,
Anthony

--
Cheers, Stuart

[Kevin Bourrillion]

Hi Anthony,

First off, your code is going to depend on some interfaces like Module and Provider anyway, so your change with the annotations doesn't really change anything.  I do think it would make sense for us to put these common interfaces and annotations into their own small JAR file, so you can feel more light and airy when you depend on only that, and there is a feature request filed for it (I don't remember if Bob and Jesse agree, though).

Beyond that, I think that some people, when seeing "import com.google.inject.Inject", simply imagine a problem where none really exists.  We all work so hard at keeping dependencies out of our code that when we see that we react against it at a gut level.  But in reality, your classes have no runtime dependency on Guice. If they run as part of an application that doesn't wish to use Guice, the Guice jar file needn't even be present on the server at all.

The idea of "dependency" or "tight coupling" is that "the one cannot function without the other." But with annotations, this isn't the case.  They're just decoration that don't, and can't, actually do anything. They sit there, innocuously, in case tools will wish to read them, and otherwise have no effect whatsoever. They don't impede you from testing your code, or from using the classes with Spring or just using them normally.

Hopefully this explains why we have never been convinced there's an actual problem here.

[Dhanji R. Prasanna]

Kevin,

I don't think there's any need to separate the annotations either.
Java jars sit there innocuously unless they're being used. The only
(sortof) argument might be where struts2's @Inject interferes with
Guice's.

But I've not heard anyone complain about that before.

Dhanji.

[Anthony MULLER]

Thanks for your feedbacks!

I work for a major software editor and "dependencies" with external 3tr party, like Guice can be see as a problem. Personally, I don't care about this point (having @Inject from Google package in my code).

But, we are working on a kind of platform and independence is one of the main concerns. So, ok Provider and Module are already in the code but there are easily hidden into the bootstrap code. I can not do anything for @Inject annotation...

I will look at links from Stuart...

Cheers!

Anthony

2008/12/13 Dhanji R. Prasanna <dha...@gmail.com>

[Putrycz, Erik]

The pico container has a solution for the @Inject annotation and enables to set any custom annotation for injection. This way you don’t need to bind any of your code to the IoC framework.

It would probably be worth putting a feature request for this…

 

Erik.

 

---

[Kamil Demecki]

On Dec 22, 6:11 pm, "Putrycz, Erik" <Erik.Putr...@nrc-cnrc.gc.ca>
wrote:

> The pico container has a solution for the @Inject annotation and enables
> to set any custom annotation for injection. This way you don't need to
> bind any of your code to the IoC framework.
>

> It would probably be worth putting a feature request for this...
>

+1

[Putrycz, Erik]

This one is already discussed here http://code.google.com/p/google-guice/issues/detail?id=70 and limpbizkit answer was "I think this is more of a 'perceived' problem than a real problem.".

> -----Original Message-----
> From: google...@googlegroups.com [mailto:google...@googlegroups.com]

[Kamil Demecki]

On Dec 23, 7:27 pm, "Putrycz, Erik" <Erik.Putr...@nrc-cnrc.gc.ca>
wrote:
> This one is already discussed herehttp://code.google.com/p/google-guice/issues/detail?id=70and limpbizkit answer was "I think this is more of a 'perceived' problem than a real problem.".
>

I commented this issue. I generally dont agree it is "perceived"
problem.