From crazyboblee on March 15, 2007 13:54:14

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).

From james.strachan on March 16, 2007 02:19:15

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; }
})

From ajoo.email on April 27, 2007 08:24:07

+1

From ivanobulo on May 02, 2007 05:32:37

-1

From skalinic on May 23, 2008 13:51:14

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?

From limpbizkit on June 04, 2008 22:58:16

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?

Labels: -Priority-Medium Priority-Low

From stolsvik on June 05, 2008 01:08:56

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".

From skajotde on December 25, 2008 09:55:28

+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.

From robbie.vanbrabant on December 26, 2008 03:40:36

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.

From robbie.vanbrabant on December 26, 2008 03:46:01

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

From stolsvik on December 26, 2008 06:58:26

@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.

From skajotde on December 26, 2008 08:06:58

"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.

From skajotde on December 26, 2008 08:24:55

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.

From mcculls on December 26, 2008 08:39:35

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.

From robbie.vanbrabant on December 26, 2008 16:54:54

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?

From robbie.vanbrabant on December 26, 2008 17:01:48

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

From limpbizkit on December 26, 2008 19:12:55

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.

From erik.putrycz on December 27, 2008 00:08:11

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

From stolsvik on December 27, 2008 09:08:51

@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.

From jose.illescas on February 09, 2009 10:59:11

See patch on https://code.google.com/p/google-guice/issues/detail?id=258 note: runtime injection across custom provider to simplifying our "Annotation
Frameworks"  (It´s cool)

From james.strachan on April 03, 2009 02:54:45

IMHO we can mark this as complete - as is https://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

From limpbizkit on April 03, 2009 17:47:23

Yay!

Status: Fixed

From dhanji on April 03, 2009 17:56:03

We still need bind toCtor...