square
Listing a class as an entry point should not make instantiable via @Inject
When you list a class as an entry point in a module's inject parameter, dagger will allow you to @Inject it into other classes. But if you could do that safely, you likely would have annotated its constructor, or built a provider method for it.
As it stands our Android apps have generated getApplication() methods which only do bad things if we ever make the mistake of calling them — like waste a day of my life tracking down an obscure bug caused by some test code that naively was doing just that.
We shouldn't generate those methods, and attempting to @Inject such a class should fail as fast as possible.
agreed. I don't think the injects attribute should be magically also a provider.
Oh - wait. we're making classes listed in injects= a provider? I don't think we do that - we create a deferredbinding for it, but I thought we need a membersinject or provides binding for it to matter.
Can we replicate this with a test case, I'm not sure I'm following what's wrong here.
actually, I have doubts, too..
Since #232 is implemented, aren't entry points required to have an @Inject annotation (or be supplied via @Provides)? If that's the case, isn't this issue unsolvable without undoing #232?