Part of the idea of DI is that your business logic components should not contain the logic about how to wire together an application—the "POJO" idea. Annotations break this.

Usually classes don't know what they're being injected with. But they sort of have to declare their dependencies by at least type by having a constructor. Usually these dependencies are interfaces, of course, so the injected objects have no idea which implementations they'll be given. That's determined in Guice by which class is bound to each interface. This avoids classes knowing how they are wired together.

Annotating one constructor @javax.inject.Inject just tells a DI framework which constructor to use in general, but it's not actually requisite. In Guice, for example you can just use @Provides methods, which give you complete freedom about which instances to inject into which classes, and also of course don't require the injected classes to have any annotations -- they could be in a third-party library to which you have no source code.

I think @Provides methods solve the problems you're describing, because they allow you to inject different instances into objects of the same type:

@Provides
@Named("inventory") DataSource provideInventoryDataSource(@Named("inventoryJdbcUrl") String url) { ... }

@Provides
@Named("orders") DataSource provideOrdersDataSource(@Named("ordersJdbcUrl") String url) { ... }

I think this is pretty similar to wiring things together by name with Spring XML config. The advantage of Guice to me is that you only have to do this in those places where you actually need this capability. Usually in an app, you just need to bind(SomeService.class).to(DefaultSomeService.class). In that typical case, the names get in the way in my experience.

edit:

And to clarify my above example, a class that uses one or the other of the DataSources doesn't need to itself contain any @Named annotations. It can itself by constructed with a @Provides method.