Comments (6)
Or, alternatively, outright forbid them.
from dagger.
I haven't even tried ‡ with Java 8. Right now does it not provide an implementation?
As far as the example goes, I don't think there's actually any issue with it in particular. Marking the component as @Singleton
just says that it may contain singleton bindings. If you have a default method that returns a new TwitterApi
per invocation, that's just like having a @Provides
method that wasn't singleton in that component. I suppose you could mark that method @Singleton
, but that would be super confusing I would think… we'd have to do something like ensure that bindings in the modules match the binding on the method or something. Ick.
Anyway, I'm tempted to just forbid them because I can't think of a reason that you'd actually want to do this. The problem is that I'm not sure that there's a good/clean way to do that in a processor that works under 1.7.
from dagger.
Right. The generated implementation does not include an override nor does it seem to include it in validation checking. I don't even know what the least-astonishing behavior would be here...
Not sure there's any real value in having default
methods on components. Presumably it's the same value as having them on normal interfaces: evolution without changing downstream consumers. I'm just trying to break things before the masses get their hands on this.
I think you'd have to .name()
the Modifier
and do a string comparison in order to check in a compatible way if you did want to reject them outright.
from dagger.
I feel like the fact that we generate implementations means that a primary use case of default methods is sort of N/A anyway.
from dagger.
I'm marking this as a 2.1 release issue to resolve Java 8 default method behavior. In the mean-time it's specifically undefined behavior.
from dagger.
Why wouldn't we treat default methods on @Component
interfaces just like concrete methods on @Component
classes? That is, don't override them because they're not abstract.
In your example @JakeWharton, I don't see why you would expect two calls to api()
to return the same thing. You've provided OKHttpClient
as a @Singleton
, not TwitterApi
. Even if you meant to provide TwitterApi
as a @Singleton
, the api()
method doesn't read to me as a component provision method, because it's not abstract.
from dagger.
Related Issues (20)
- Subcomponent MembersInjector error in 2.51 HOT 1
- Does Hilt always execute app module during instrumented test? HOT 3
- [KSP] Dagger-KSP does not see typealiased dagger annotations HOT 3
- Cannot invoke getAnnotationValue because "annotation" is null HOT 14
- Creator-less subcomponents are not visible to modules HOT 1
- Suggestion to add isInit() api to dagger.Lazy HOT 1
- [Error] : java.lang.ClassNotFoundException: Didn't find class "com.myproject.MainApplication" on path: DexPathList HOT 1
- K2 KAPT (aka KAPT4) doesn't like inline/reified. HOT 3
- [KSP2] ClassCastException: class KSClassDeclarationEnumEntryImpl cannot be cast to class XEnumEntry HOT 2
- Hilt: Injection not working in BroadcastReceiver HOT 3
- Assisted injection appears to not work correctly in some cases HOT 3
- [Dagger/MissingBinding] com.xxx.onboarding.presentation.otp.LoginViewModel cannot be provided without an @Inject constructor or an @Provides-annotated method. public abstract static class SingletonC implements SemaaiApplication_GeneratedInjector HOT 1
- Hilt Class Generation Fails After Upgrading to AGP 8.5.1 from 8.0.1 HOT 6
- Issue with Dagger Hilt Upgrade from 2.48 to 2.49 - Unable to Load Class JavacBasicAnnotationProcessor HOT 1
- Way to replace a dependency created using Constructor Injection for all tests using Hilt. HOT 4
- After updating from 2.51.1 to 2.52, my GWT application does not compile HOT 1
- NPE On Lazy Dagger
- [KSP] Component processing is not deferred if there are unresolved symbols in the current round HOT 2
- [KAPT] - Issue build type release AGP 8.4.0 - 8.5.2 Kotlin 1.9.24 and Dagger 2.52
- SomeClass$LazyClassKeyProviders.class generated by Dagger/Hilt is not deterministic
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from dagger.