It sounds like what you're trying to do is to bind different varieties of Music based on the annotation on the User. This is also called the Robot Legs problem, except you can replace "Leg" with "User" and "Foot" with "Music". This is possible using Private Modules in Guice, but you may find it easier to create a UserFactory instead. I'll show you both ways.
First, the Private Module way. Private modules hide all of their bindings from the outside world, so you can expose certain ones without having the others conflict.
public class MyModule extends AbstractModule {
@Override protected void configure() {
install(privateModuleFor("user1", RockMusic.class));
install(privateModuleFor("user2", PopMusic.class));
}
private static Module privateModuleFor(
final String userName, final Class<? extends MusicInterface> musicClass) {
return new PrivateModule() {
@Override protected void configure() {
// Bind the annotated user.
bind(User.class).annotatedWith(Names.named(userName)).to(User.class);
// Now bind the music class as if it's the only music class ever.
bind(MusicInterface.class).to(musicClass);
// The above two bindings are hidden, and available only in this module,
// so Guice doesn't complain about two different competing
// MusicInterfaces. In order to get access to the User binding
// outside the module, expose it.
expose(User.class).annotatedWith(Names.named(userName));
}
};
}
}
Now you can request a @Named("user1") User to get a User that likes rock music. Of course, you don't have to organize it like I did with the method: You can still bind the types of MusicInterface to names if you'd like, and then bind the annotation-less MusicInterface to Key.get(MusicInterface.class, yourMusicTypeHere) in your PrivateModule, but unless you need the named MusicInterfaces elsewhere you can probably skip that step.
The other way is to skip using Guice for this binding. Guice is a great solution, but for some complicated binding situations it can be more trouble than it's worth to set up. Your alternative is to create a lightweight UserFactory that picks the right type of Music for you. (ImmutableMap is from Guava.)
public class UserFactory {
private Map<String, Class<? extends MusicInterface>> musicMap =
ImmutableMap.builder()
.put("user1", RockMusic.class) // You could also put instances here
.put("user2", PopMusic.class) // and skip using Guice entirely!
.build();
// Never inject Injector unless you don't know what you need until runtime,
// which is exactly what is happening here.
@Inject private Injector injector;
@Inject private Provider<Dependency> someOtherUserDependency;
public User createUser(String musicType) {
Class<? extends MusicInterface> clazz = musicMap.get(musicType);
return new User(injector.getInstance(clazz), someOtherUserDependency.get());
}
}
Now your User will be available by injecting UserFactory and calling userFactory.create(). Of course, maybe your User needs a dozen other injected dependencies. In that case, the first option looks good, or you may investigate assisted injection. All of these are workable options, so you'll need to think about which one is the right combination of flexibility and readability for your situation.
Hope that helps!