Spring 3 constructor injection anomaly: documentation vs. reality

Question

Facts

Spring 3.2 documentation (http://docs.spring.io/spring/docs/3.2.9.RELEASE/spring-framework-reference/htmlsingle/#beans-constructor-injection):

When another bean is referenced, the type is known, and matching can occur (as was the case with the preceding example). When a simple type is used, such as true, Spring cannot determine the type of the value, and so cannot match by type without help.

package examples;

public class ExampleBean {

    // No. of years to the calculate the Ultimate Answer
    private int years;

    // The Answer to Life, the Universe, and Everything
    private String ultimateAnswer;

    public ExampleBean(int years, String ultimateAnswer) {
        this.years = years;
        this.ultimateAnswer = ultimateAnswer;
    }
}

In the preceding scenario, the container can use type matching with simple types if you explicitly specify the type of the constructor argument using the type attribute. For example:

<bean id="exampleBean" class="examples.ExampleBean">
    <constructor-arg type="int" value="7500000"/>
    <constructor-arg type="java.lang.String" value="42"/>
</bean>

My class:

package client;

public class Client {

    private int id;
    private String name;

    public Client(int id, String name, String email) {
        super();
        this.id = id;
        this.name = name;
    }

}

bean definition:

<bean id="someClient" class="client.Client">
    <constructor-arg value="5"></constructor-arg>
    <constructor-arg value="5"></constructor-arg>
    <constructor-arg value="5"></constructor-arg>
</bean>

Problem

I would have expected that the Spring IoC container will fail to create the bean someClient, since as stated above, it should be unable to address the types of constructor arguments specified. But, again, according to the docs a bit earlier:

If no potential ambiguity exists in the constructor arguments of a bean definition, then the order in which the constructor arguments are defined in a bean definition is the order in which those arguments are supplied to the appropriate constructor when the bean is being instantiated.

But alas, Spring registers the someClient bean effortlessly. This seems like a contradiction to me.

Question

So what is an ambiguous situation, according to Spring? The above example is clearly not ambiguous, Spring happily supplies the arguments in the order as they are defined in the bean definition. When is it really useful to use name/index attributes in the bean definition?

Answer 1

Consider this

<constructor-arg value="5"></constructor-arg>

You haven't specified a type, but a 5 can easily be converted to a String, or any of the numerical types. Similarly, and as an example,

<constructor-arg value="java.lang.String"></constructor-arg>

Spring can produce a String or a Class object as an argument. If a constructor was available for each of those types, then there would be ambiguity. If only one constructor exists, then the appropriate conversion strategy for that constructor will be used.

There's no ambiguity if there is only one constructor.