Here are my thoughts on that stuff:
@ImplementedBy provides a sensible default (great for frameworks) if no binding
exists
Overriding @ImplementBy via a binding is expected
Overriding @Inject via a Provider is expected (and the standard use-case for
providing alternate construction)
@Singleton is not part of construction/injection but part of scoping. @Inject,
@ImplementedBy, and Provider are all part of construction/injection
In all other cases (@ImplementedBy, non-scoped binding, default construction,
etc) @Singleton is honored
There are two pieces of this to consider:
The scope of the Provider
The scope of the instance created by the Provider
I don't know if #1 can be controlled or not, but I'm assuming it can't. On the
other hand, #2 is only controlled via a binding unless a Provider method is
used and then the annotation on that method is honored.
The one major concern I have regarding this would be performance. As I've
thought about it a bit more, it seems as though in all other cases the
@Singleton provides information when the Injector is being created and Guice
can make determinations up front. Furthermore, this would not allow Singleton's
to be eagerly created. Therefore, it probably would incur significant overhead
at runtime as well as preventing eager creation.
Based on that, I think it is best avoided.
-bp
On Aug 31, 2010, at 8:56 AM, Fred Faber wrote:
> I don't think that syncs entirely with the POLS. Consider another use case:
>
> class Foo {
> @Inject Foo() { ... }
> }
>
> bind(Foo.class)
> .toProvider(new Provider<Foo>() {
> @Override public Foo get() {
> return new Foo(..);
> }
> });
>
> here, the @Inject annotation is wrongly put on the constructor of Foo.
>
> I believe this is directly analogous to annotating Foo with @Singleton and
> expecting that to be respected. This is to say that it is sensible to ignore
> the annotation when the binding is explicitly overriding it.
>
> This is a good illustration of why bindings should, in general, be made as
> explicit as possible within their associated modules. Another example is the
> somewhat ill-advised use of the @ImplementedBy() annotation. Again, we could
> see that annotation become ignored if an explicit binding was added.
>
> -Fred
>
> On Tue, Aug 31, 2010 at 8:53 AM, Brian Pontarelli <[email protected]>
> wrote:
> Right. That's my fix. I was probing for discussions not solutions. I'm
> inclined to say that if a class has Singleton on it, it should be honored.
> However, this impacts existing applications that are attempting to override
> the Singleton annotation via a Provider. But I would hope that isn't common.
>
> I've honestly never looked at the code, but I would assume that looking for
> annotations on instances returned from Providers would be simple enough.
>
> -bp
>
>
> On Aug 30, 2010, at 7:50 PM, Bob Lee wrote:
>
>> Guice only looks at the annotation on the class when it directly creates
>> instances of that class.
>>
>> You want:
>>
>> bind(MyInterface.class).toProvider(MyProvider.class).in(Scopes.SINGLETON);
>>
>> Thanks,
>> Bob
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "google-guice" group.
>> To post to this group, send email to [email protected].
>> To unsubscribe from this group, send email to
>> [email protected].
>> For more options, visit this group at
>> http://groups.google.com/group/google-guice?hl=en.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "google-guice" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/google-guice?hl=en.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "google-guice" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/google-guice?hl=en.
--
You received this message because you are subscribed to the Google Groups
"google-guice" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/google-guice?hl=en.
