Support any annotation in place of @Inject

[GoogleCodeExporter]

Allow any annotation to be used in place of @Inject.  I believe we would
not provide the ability to disable recognition of @Inject itself, only
allow additional annotations to also serve.

A couple possible solutions.

1. The "surrogate annotation" pattern.  The user uses their own @MyInject
annotation, and they annotate *this* annotation itself with @Inject. Guice
follows this, treating @MyInject as an "alias".  Upside: very very simple
to use.  Downside: your implementation code now still has a dependency to
guice, it's just been made indirect.

2. Binder.addInjectAnnotation(MyInject.class).  This way a module can
contribute an additional annotation to recognize as being an injection
annotation, and it will automatically become recognized for any class in
your application.  Upside: implementation classes have no dependency to
Guice even indirectly.  The only thing that remains special about @Inject
itself is that the Injector happens to addInjectAnnotation() for it
automatically.  Downside: I don't see how we could support recognizing the
new annotation "for this module only"; it would probably have to just
automatically apply to everything.  People might dislike this, but it's
actually no different from binding an interface -- if your interface is
public, guice is not in the business of stopping anyone from depending on
it who wants to; that's the job of other tools.

3. Others?

Original issue reported on code.google.com by kevin...@gmail.com on 15 Mar 2007 at 5:58

[GoogleCodeExporter]

I'm not sure 2 is worth it. You still have binding annotations. I suppose we 
could do
the same for them, but is it worth it?

I almost think it's better to not worry about this now and concentrate on
standardization instead (i.e. JSR 299).

Original comment by crazybob...@gmail.com on 15 Mar 2007 at 8:54

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I really like this idea too BTW. There's lots of frameworks which have their own
annotations (EJB3, Spring, Stripes, SCA et al) so it'd be nice to bind those
annotations to guice's injection pointcuts in a module.

One nit is being able to figure out whether an injection point is mandatory or
optional - so we might want some kinda little functor to return the
mandatory/optional nature...

Binder.addInjectAnnotation(MyInject.class, new InjectionStatus<MyInject>() {
  public boolean isMandatory(MyInject my) { return my.mandatory(); }
})

This would work if an annotation meant mandatory or optional. e.g. for EJB3

Binder.addInjectAnnotation(Resource.class, new InjectionStatus<Resource>() {
  public boolean isMandatory(Resource my) { return true; }
})

Original comment by james.st...@gmail.com on 16 Mar 2007 at 9:19

[GoogleCodeExporter]

+1

Original comment by ajoo.em...@gmail.com on 27 Apr 2007 at 3:24

[GoogleCodeExporter]

-1

Original comment by ivanob...@gmail.com on 2 May 2007 at 12:32

[GoogleCodeExporter]

I think that a well-defined set of default injection rules can go a long way 
toward 
eliminating the compile dependency.

I think there is a large enough subset of use cases when the binder could 
figure out 
what to inject without an explicit @Inject annotation. For example, very often 
a 
class would have a single constructor, or all constructors of the class would 
be 
fair game for injection. In these and similar cases the only bit of information 
the 
binder needs is the knowledge that the class must be injected. This can be 
communicated to the binder (for example, by calling a static 
Binder#injectConstructors(Class) method), freeing the class from the 
compile-time 
dependency altogether.

What do you think?

Original comment by skali...@gmail.com on 23 May 2008 at 8:51

[GoogleCodeExporter]

I think this is more of a 'perceived' problem than a real problem. What 
applications cannot be written because 
of this limitation? How would this increase productivity?

Original comment by limpbizkit on 5 Jun 2008 at 5:58

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

I think it is a very fair wish: one does not want to bind to a specific
implementation of ANYTHING, even if it is made at Google. The fact is that it 
is ONLY
Guice of all IoC frameworks that really messes with your code, and kinda makes 
it
"non-POJO": You have to annotate it. With the current version of Guice, you 
actually
have to annotate it with annotations outside of your own code - from a fully
non-standard library.

I do agree with Bob on Comment 1, focus on standardization. In particular, is 
should
be possible for Guice to at least honor the common existing annotations for 
Java, JSR
250. Either natively, or by using this issues' feature: support any annotation
instead of Guice's own.
http://jcp.org/en/jsr/detail?id=250

The JSR 299 also sounded good - I believe you folks are onboard that EG? At 
least I
believe I've read some blog entries or whatever giving me that impression. How 
is it
coming along? Last movement was Dec 1 2007.
http://jcp.org/en/jsr/detail?id=299

But in the meantime, at least supporting the idea about "synonyms" to Guice's 
own
annotations seems like a really fair wish. With that, one could support the 
@Resource
oneself, and when 299 comes along, one could shove in support that, possibly in 
the
wait for Guice's implementation of it (Guice doesn't exactly move along on a
breakneck pace).

The particular issue with JSR 250 annotations is already specifically mentioned 
in
Issue 62. That issue however took up two things in one go (standard 
annotations, and
lifecycling), and became a hotbed for the issue of lifecycling (Which I also 
want!).
Please read up on both of the issues contained in Issue 62!

Finally, don't get me wrong - I think Guice is awesome! (Even though I get a bit
annoyed at some of its creators for seeming to believe that they invented IoC, 
I do
feel that they really re-invented it, and definitely got it way righter than the
XML-based stock!). Bottom line is that I don't like the fact that these 
annotations
are "Google-proprietary".

Original comment by stolsvik on 5 Jun 2008 at 8:08

[GoogleCodeExporter]

+1

this feature increase integration level with existing code. at my company major
question is why not using standards annotations like @Resource instead of 
@Inject. My
answer is testability (not needed jboss) and boost control over code. But it 
would be
great to using Guice for EJB annotations, it would solve ambiguity in using of 
IoC.

Original comment by skajo...@gmail.com on 25 Dec 2008 at 5:55

[GoogleCodeExporter]

I am always very skeptical when people talk to me about "framework 
portability". I
have never seen a company port their code to another framework without touching 
it,
and usually they don't port, they rewrite. So then the question is, should 
Guice use
@Resource instead if @Inject? My answer: when it makes it into SE, _maybe_.

So then there's the other issue people are talking about, and what Jesse called 
the
"perceived" problem. Having to import com.google.inject is indeed a perceived 
problem
from a technical perspective, but I understand that this can be a political 
problem
in larger companies. If we decide to tackle this problem I think we should 
mimic the
@Nullable feature and allow any annotation named @Inject.

Original comment by robbie.v...@gmail.com on 26 Dec 2008 at 11:40

[GoogleCodeExporter]

Correction: @Resource has been included in SE 6, it seems.

Original comment by robbie.v...@gmail.com on 26 Dec 2008 at 11:46

[GoogleCodeExporter]

@Robbie: Who is one to decide what others should find a problem? Just because 
you
find it fantastic to include a dependency on any random library, others might 
not.

Letting Guice handle other annotations than its own seems so amazingly obvious 
and
merely an extension of its own point of existence that I don't at all 
understand why
it wasn't included in the first place.

.. and definitely not why it isn't in the code now.

Reusable code is a good thing. If the code in questions tags its 
injection-needs with
its OWN annotations, it should be possible to state to the injection framework 
what
these annotations are. This instead of making a resource provider.

At this point it is even possible to use a _standard_ set of annotations. That 
Guice
should support this is, at least for me, absolutely obvious.

Original comment by stolsvik on 26 Dec 2008 at 2:58

[GoogleCodeExporter]

"I am always very skeptical when people talk to me about <<framework 
portability>>"..
I think IoC is simple contract and portability in this area is not problem from
technical side. I have seen intergeration Guice with Seam injector, JBossMC, 
Spring.
These libraries are compliant with IoC contract so integration is not heavy 
problem.
I think integration with one deep level to adjust injection point is good idea.

Original comment by skajo...@gmail.com on 26 Dec 2008 at 4:06

[GoogleCodeExporter]

People at my company prefer write standard code with @Resource (at most at 
services
level). Guice at my point of view could be using to configure this @Resource
annotations and change default behaviuor, eg create child injector and replace 
*one*
service for one test, and next test will be untouched. I think JBoss with 
@Resource
cannot do it.

Original comment by skajo...@gmail.com on 26 Dec 2008 at 4:24

[GoogleCodeExporter]

I think Robbie's suggestion of allowing other annotations named @Inject is a 
good 
compromise, as the name still shows the intent. And extending support to 
@Resource 
would also be good imho, as long as the semantics fit (don't have the spec to 
hand).

Support for any annotation would be too flexible, as it wouldn't be obvious 
where 
dependencies would be injected (@Wibble?) without first checking the 
configuration.

Original comment by mccu...@gmail.com on 26 Dec 2008 at 4:39

[GoogleCodeExporter]

To answer @mcculls' question:
http://java.sun.com/javase/6/docs/api/javax/annotation/Resource.html
It would still mean "inject here!" but all the attributes on it would not work. 
It
would probably even be confusing to have attributes set that Guice simply 
ignores.
That's what I meant with framework portability, right? Seriously, if you have to
write portable code with _any_ DI framework, you have to be very careful. You 
would
have to stick to the bare minimum, which is why people don't switch frameworks 
on
existing code. Ever used Spring's container lifecycle, FactoryBean, ... Guice's
Provider, .. ? It's like database portability. It's nice to be portable, but 
you have
to be realistic. Your company runs on Oracle? For God's sake, use those
Oracle-specific features and get it over with. :)

But indeed, let's stick to "anything named @Inject" and/or support for 
@Resource.
Maybe change the issue title?

Original comment by robbie.v...@gmail.com on 27 Dec 2008 at 12:54

[GoogleCodeExporter]

By the way there's also a downside to anything named @Inject, that is, people 
will
choose the wrong import.

Original comment by robbie.v...@gmail.com on 27 Dec 2008 at 1:01

[GoogleCodeExporter]

If we were to support any annotation with @Inject, supporting parameterized 
annotations is complicated. 
Currently we support an optional parameter, ie. @Inject(optional=true). I doubt 
we'd want to support parameters 
on third-party annotations.

That said, supporting arbitrary annotations with the 'Inject' simple name and 
no parameters is interesting.

Original comment by limpbizkit on 27 Dec 2008 at 3:12

[GoogleCodeExporter]

"supporting parameterized annotations is complicated". I think this can be done:
binder().withInjectAnnotation(MyInject.class, new OptionalRetriever() {
     boolean isOptional(MyInject annotation) {
        return annotation.optional();
     }
});

Original comment by erik.put...@gmail.com on 27 Dec 2008 at 8:08

[GoogleCodeExporter]

@Robbie: As I tried to point out: Who are you to decide how others like their 
code?!

IoC is a principle so amazingly simple that arguing around "stick with your
framework" makes no sense at all. It is FULLY possible to write code "framework
agnostic" when it comes to the IoC principle. POJO, you know.

I find those "If you use Oracle, stick to Oracle" thoughts you display here 
rather
careless. What about sticking in the obvious word "currently" in the first part 
of
that sentence? Given that, I find the latter part outright stupid.

See, some people write code that will have multi-decades lifespans. It is 
prudent to
strive towards writing "framework agnostic" code then. It makes the code way 
more
future proof, maintainable, and leaves the options open in regard to framework
provider. (I feel like I am arguing for "use standards". Do one have to argue 
for
something like that in these days?).

It seems to me that you think Guice is the end-all of pretty much any 
frameworks. I,
however, thought Spring was pretty good. But, since I wrote "framework 
agnostic" code
(what does that mean, really?! I wrote java classes taking their dependencies 
in the
constructor), it took me all of a couple of hours to throw all of Spring out the
door, instead embracing the obviously better solution that Guice gave. But I 
had to
write pretty many google-specific "@Inject" all around, giving me a feeling of 
being
sucked in to a proprietary solution that Spring never gave me. Maybe Guice 
isn't the
best implementation of IoC possible? I'd want to have the option of fully 
abandoning
it when the superior solution suddenly appears.

Original comment by stolsvik on 27 Dec 2008 at 5:08

[GoogleCodeExporter]

See patch on http://code.google.com/p/google-guice/issues/detail?id=258

  note: runtime injection across custom provider to simplifying our "Annotation
Frameworks"  (It´s cool)

Original comment by jose.ill...@gmail.com on 9 Feb 2009 at 6:59

[GoogleCodeExporter]

IMHO we can mark this as complete - as is 
http://code.google.com/p/google-guice/issues/detail?id=258

In GuiceyFruit we have already implemented @Resource injection from JSR 250 
along with @Autowired injection 
from Spring and it works like a charm on top of current trunk of Guice 2.x

Original comment by james.st...@gmail.com on 3 Apr 2009 at 9:54

[GoogleCodeExporter]

Yay!

Original comment by limpbizkit on 4 Apr 2009 at 12:47

• Changed state: Fixed

[GoogleCodeExporter]

We still need bind toCtor...

Original comment by dha...@gmail.com on 4 Apr 2009 at 12:56