[Dagger/DuplicateBindings] if component's dependencies extends two or more interfaces with same method

[Tagakov]

@Component(dependencies = Comp.Combined.class)
interface Comp {
    interface A {
        String s();
    }
    interface B {
        String s();
    }

    interface Combined extends A, B {
//        uncomment to make it compile
//        @Override
//        String s();
    }

    String s();
}

Error:

[Dagger/DuplicateBindings] java.lang.String is bound multiple times:
interface Comp {
^
      String com.example.playground.Comp.A.s()
      String com.example.playground.Comp.B.s()
      java.lang.String is provided at
          com.example.playground.Comp.s()

Looks like this issue is related to #472

Is it the intended behavior? At first glance, it looks like dagger shouldn't treat methods inherited from different interfaces as duplicate bindings if they have the same signature and qualifiers.

[nlgtuankiet]

What is the use case of this?

[Tagakov]

When interfaces A and B are quite big and you have to extend both it becomes hard to identify the intersection between them, also overridden methods doesn't bring any new information to the reader and bloats Combined interface with unrelated methods.

For example, we are using a hierarchy of @Components. Each @Component declares its own Dependencies which user should fulfill to instantiate that component. And in the case when one @Component A should be instantiated inside another @Component B component's B dependencies could extend the component's A dependencies.

@Component(dependencies = A.Dependencies.class)
interface A {
  interface Dependencies {
    //...
  }
}

@Component(dependencies = B.Dependencies.class)
interface B {
  interface Dependencies extends A.Dependencies, C.Dependencies, Etc.Dependencies {
    //...
  }
}

[Tagakov]

ping?

[Neronse]

same problem, Is there a solution to that?

[Chang-Eric]

Going to work on fixing this, though FWIW this is still going to be somewhat fragile for you since it depends on naming of the methods. So if those two interfaces that presumably live apart name the getters differently, things will break and there won't really be a good answer to fixing it besides making the names match or factoring out shared deps into a single interface.