Dagger: Hilt is not compatible with pure Java Gradle modules

[dandc87]

Our project has a number existing Java Gradle modules which expose Dagger modules. We cannot migrate these to use Hilt because the hilt-android artifact is an AAR, which is incompatible.

Could some of the Android-agnostic annotations and interfaces be extracted to a separate hilt jar artifact? (at least @InstallIn, @AliasOf, and the standard component interfaces)

I imagine that these are all bundled together be certain everything is on the classpath of generated code, but feel a workable subset could be extracted without too much headache?

[Chang-Eric]

This is something we're aware of/thinking of a better answer, but it is complicated by the fact that the standard component interfaces are tied to Android. I don't know that it makes sense to refer to dagger.hilt.android.components.ApplicationComponent from a non-Android module. And since all components are currently children of that component, making @InstallIn available outside of that wouldn't be helpful.

Right now the best you can do is probably just create non-Hilt modules there and then @Modules(include) them in a Hilt Dagger module from an Android Gradle module.

[dandc87]

That is probably the path we will follow for now.

My 2 cents is that since Hilt bills itself as a DI solution for Android, a Java-compatible base artifact would make sense for a "Java Gradle module in an Android project" use case. And since the component interfaces are only logically tied to Android (they don't require Android classes), they could be included in a jar artifact instead. And if you really want separation, it could be hilt and hilt-android-components or something.

[Chang-Eric]

@dandc87 or anyone else following this - We have a plan that I think would work to allow usage of the ApplicationComponent in non-Android modules. Does this cover your use case or do you have bindings in non-Android modules that are bound to say the ActivityComponent?

The reason I think this makes sense for us is that @Singleton bindings can often make sense as just a general concept, but it is kind of hard to think of something that would be @ActivityScoped or something but not have a dependency on Android.

[dandc87]

Does this cover your use case [...]?

Not entirely. But it would address the majority of our existing bindings.

[julioromano]

Does this cover your use case

Mostly. Even though we don't scope pure java stuff at the Fragment or View level, we do scope pure java stuff at the ViewModel level (i.e. ActivityRetainedComponent).

[kakai248]

The hilt-core artifact contains the core (non-Android) Hilt APIs. Note that this artifact is only meant to be used by pure Java/Kotlin libraries within an Android application.

Just curious: why the within an Android application limitation? Wouldn't SingletonComponent also make sense for other type of applications?

Is it because the InstallIn behavior is only supported in hilt, which only works as a whole in Android applications?

[bcorso]

Wouldn't SingletonComponent also make sense for other type of applications?

Yep, that's actually why we did the rename from ApplicationComponent -> SingletonComponent. We'll be looking into non-Android applications eventually, but we're currently focused on getting Hilt for Android out of alpha.