Having to deal with Guice, I wonder how I should handle dependencies in terms of modules.
In Guice every module is provided by an instance. So if I have a module req
Binding deduplication looks to have been added in Guice 4.0
https://github.com/google/guice/commit/c34e0185fcf508a890c6cd13bdafeb505c3e9e8a
Since Guice do not support certain needed functionality it must be emulated. The multibinder code provides one idea. Another idea I currently use is using reflection to find the top most binder during the injector build process. Knowing this binder one can easily add required meta information and track certain objects.
Those meta information will be dropped once the build process finished.
Usually one only builds one injector at a time but to be sure we should protect against this.
So take a look at the single most Binder implementation (RecordingBinder). It provides a field parent that we can walk to the root binder element. Usually Guice will use a single most binder but in case of private modules.
Another idea being not so secure but come without reflection is using a thread local if you can ensure that only one Guice injector is build at a time.
Being able to identify the build process and track which builders are used at a time one is able to add any kind of additional logic into guice like preventing to install a dependency twice.
Guice has two features to deal with this situation. The first is module de-duplication. This means that if two modules are installed that are equivalent (by equals() and hashCode()), only one's configure() method will run. However, this solution is somewhat brittle because it won't survive SPI transformations, Modules.override(), etc.
The second, and IMO better solution, is binding de-duplication. This means that Guice will accept bindings that are exact duplicates. So if your module does bind(Interface.class).to(Implementation.class), it doesn't even matter if its configure() method runs twice, because Guice will handle the duplicate binding just fine.