Autowiring inconsistency: @Qualifier works with HashMap but not with Map [SPR-17197]

[spring-projects-issues]

Manfred Quasten opened SPR-17197 and commented

bean definition:

<bean id="instances" class="java.util.HashMap" >
 <constructor-arg>
 <map key-type="java.lang.String" value-type="java.lang.String">
 <entry key="0001" value="Beschreibung " />
...
 </map>
 </constructor-arg>
</bean>

public InstanceRepositoryImpl {

@Autowired
 InstanceRepositoryImpl(@Qualifier("instances") final Map<String,String> instances ) {
 this.instances= instances;
 }

}

 

Error Message:

No qualifying bean of type 'java.util.Map<java.lang.String, java.lang.String>' available: expected at least 1 bean which qualifies as autowire candidate. Dependency annotations: {@org.springframework.beans.factory.annotation.Qualifier(value=instances)}

When I change Map to HashMap<String,String> it works: no exception is thrown.

It should work using the Map interface. The  @Qualifier annotation specifies the name; the bean exists.

---

Affects: 5.0.3

Issue Links:

• Accept empty Collection<Component> injection for single constructor scenarios [SPR-15338] #19901 Accept empty Collection injection for single constructor scenarios
• Ordered list access for BeanFactory.getBeanProvider(), superseding ObjectProvider<List> [SPR-17272] #21805 Ordered list access for BeanFactory.getBeanProvider(), superseding ObjectProvider

[spring-projects-issues]

Juergen Hoeller commented

This difference originates in Spring's special handling of collection/map interface types which might be an an aggregated set of several target beans, or a single target bean which implements the collection/map type itself. For a full generic type match, this will cleanly resolve... but for a 'raw' type match between a collection interface and a target bean with unresolved generics (since your target HashMap is a plain type with erased generics), our algorithm backs out since it does not consider those a clear enough match.

An @Bean factory method for the target collection can declare its generics in the return type signature, which is one way to make this resolve cleanly. Also, a more specific dependency type (such as HashMap) is considered a hint that a single target bean is desired even if the generics cannot be resolved. And as of 5.1, we consider qualifier matches as a clear enough hint that a bean with unresolved generics is a match in such a scenario now.