com.google.inject.multibindings Documentation Differences

This file contains all the changes in documentation in the package com.google.inject.multibindings as colored differences. Deletions are shown like this, and additions are shown like this.

If no deletions or additions are shown in an entry, the HTML tags will be what has changed. The new HTML tags are shown in the differences. If no documentation existed, and then some was added in a later version, this change is noted in the appropriate class pages of differences, but the change is not shown on this page. Only changes in existing text are shown here. Similarly, documentation which was inherited from another class or interface is not shown here.

Note that an HTML error in the new documentation may cause the display of other documentation changes to be presented incorrectly. For instance, failure to close a <code> tag will cause all subsequent paragraphs to be displayed differently.

An API to bind multiple map entries separately, only to later inject them as a complete map. MapBinder is intended for use in your application's module:

 public class SnacksModule extends AbstractModule {
   protected void configure() {
     MapBinder<String, Snack> mapbinder
         = MapBinder.newMapBinder(binder(), String.class, Snack.class);
     mapbinder.addBinding("twix").toInstance(new Twix());
     mapbinder.addBinding("snickers").toProvider(SnickersProvider.class);
     mapbinder.addBinding("skittles").to(Skittles.class);
   }
 }

With this binding, a Map{@code } can now be injected:

 class SnackMachine {
   {@literal @}Inject
   public SnackMachine(Map<String, Snack> snacks) { ... }
 }

In addition to binding {@code Map}, a mapbinder will also bind {@code Map>} for lazy value provision:

 class SnackMachine {
   {@literal @}Inject
   public SnackMachine(Map<String, Provider<Snack>> snackProviders) { ... }
 }

Contributing mapbindings from different modules is supported. For example, it is okay to have both {@code CandyModule} and {@code ChipsModule} both create their own {@code MapBinder}, and to each contribute bindings to the snacks map. When that map is injected, it will contain entries from both modules.

The map's iteration order is consistent with the binding order. This is convenient when multiple elements are contributed by the same module because that module can order its bindings appropriately. Avoid relying on the iteration order of elements contributed by different modules, since there is no equivalent mechanism to order modules.

The map is unmodifiable. Elements can only be added to the map by configuring the MapBinder. Elements can never be removed from the map.

Values are resolved at map injection time. If a value is bound to a provider, that provider's get method will be called each time the map is injected (unless the binding is also scoped, or a map of providers is injected).

Annotations are used to create different maps of the same key/value type. Each distinct annotation gets its own independent map.

Keys must be distinct. If the same key is bound more than once, map injection will fail. However, use .permitDuplicates() in order to allow duplicate keys; extra bindings to {@code Map>} and {@code Map>} will be added.

Keys must be non-null. {@code addBinding(null)} will throw an unchecked exception.

Values must be non-null to use map injection. If any value is null, map injection will fail (although injecting a map of providers will not). @author dpb@google.com (David P. Baker)

An API to bind multiple values separately, only to later inject them as a complete collection. Multibinder is intended for use in your application's module:

 public class SnacksModule extends AbstractModule {
   protected void configure() {
     Multibinder<Snack> multibinder
         = Multibinder.newSetBinder(binder(), Snack.class);
     multibinder.addBinding().toInstance(new Twix());
     multibinder.addBinding().toProvider(SnickersProvider.class);
     multibinder.addBinding().to(Skittles.class);
   }
 }

With this binding, a Set{@code } can now be injected:

 class SnackMachine {
   {@literal @}Inject
   public SnackMachine(Set<Snack> snacks) { ... }
 }

If desired, Collection{@code >} can also be injected.

Contributing multibindings from different modules is supported. For example, it is okay to havefor both {@code CandyModule} and {@code ChipsModule} to both create their own {@code Multibinder}, and to each contribute bindings to the set of snacks. When that set is injected, it will contain elements from both modules.

The set's iteration order is consistent with the binding order. This is convenient when multiple elements are contributed by the same module because that module can order its bindings appropriately. Avoid relying on the iteration order of elements contributed by different modules, since there is no equivalent mechanism to order modules.

The set is unmodifiable. Elements can only be added to the set by configuring the multibinder. Elements can never be removed from the set.

Elements are resolved at set injection time. If an element is bound to a provider, that provider's get method will be called each time the set is injected (unless the binding is also scoped).

Annotations are be used to create different sets of the same element type. Each distinct annotation gets its own independent collection of elements.

Elements must be distinct. If multiple bound elements have the same value, set injection will fail.

Elements must be non-null. If any set element is null, set injection will fail. @author jessewilson@google.com (Jesse Wilson)

A visitor for the multibinder extension.

If your BindingTargetVisitor implements this interface, bindings created by using Multibinder or, MapBinder or OptionalBinderBinding will be visited throughthrough this interface. @since 3.0 @author sameb@google.com (Sam Berlin)