Spring can't find lower visibility constructor if a public default constructor exits

[howitzer]

Apologies if this question has been answered before on the forum. If so, please point me to the thread as I have been unable to find it.

Spring appears to be unable to find constructors with arguments and access modifier less than public when default public constructor is present.

Consider the class:

package test;
public SimpleBean {
public SimpleBean() {}
private SimpleBean(String x) {}
}

Context configuration:
<bean id="simpleBean" class="test.SimpleBean">
<constructor-arg value="test" />
</bean>

Spring throws the following exception:

org.springframework.beans.factory.BeanCreationExce ption: Error creating bean with name 'simpleBean' defined in class path resource [test/Test-context.xml]: 1 constructor arguments specified but no matching constructor found in bean 'simpleBean' (hint: specify index and/or type arguments for simple parameters to avoid type ambiguities)

Everything works fine (no exceptions) if
1. The public default constructor is removed or its signature is changed to accept some argument.
2. The access modifier of the zero argument constructor is anything less than public.

The class's design notwithstanding, any ideas why Spring throws this exception?

[howitzer]

https://jira.springframework.org/browse/SPR-7453

[dgahlawat@yahoo.com]

My question is should this be allowed? If we allow that we can never guarantee any class to be singleton.

[howitzer]

I take it you mean whether Spring should allow it or now. I believe that if Java allows something, Spring shouldn't restrict it.

From a Java perspective, I don't see why there should be a restriction on a combination of constructors with different access modifiers.

A singleton is a design pattern, not a coding restriction. Ultimately, not all development pitfalls (like guaranteeing a singleton) can be avoided through language limitations.

This can be a very interesting and long discussion but I think it transcends the boundaries of this forum.

[dgahlawat@yahoo.com]

Thanks for the clarification howitzer. May I ask why do you anyway need to create a bean using the constructor which is private, in your context? I dont think we have much uses when we have a constructor private and singleton is one of them and I am sure this (spring access to private constructor) is going to break those logics as well.
As far as language is concerned, I believe when we make a constructor private in java it will never be called from the scope outside class, and we are breaking this rule as well here as some 3rd party (Spring) bean has VIP access to our class.

[howitzer]

As such the issue stands even if the other constructor is protected or default and a public default constructor exists.

In this particular case, I hit this problem when I was trying to create a class using the Apache Digester. I used the same class to be the digested representation of the XML as well as the consumer for the digested representation. I provided the private constructor for Spring to inject the XML resource and the default constructor to enable digester to create instances of the object.

Of course, this can be designed in many other ways but in theory if Spring has the capability to invoke private constructors (as also, set the values of private properties, invoke private methods and instantiate inner classes), it should have been able to invoke my private constructor.

Therefore in my first post I said 'The class's design notwithstanding.....'

[dgahlawat@yahoo.com]

OK I completely agree from your point of view but somehow I still believe that spring should not expose the private property/constructors/methods to developers.. it can be risky and breaks the laws of abstraction!! This means that there is nothing private in spring application and we cannot ensure the safety of any property.

[Marten Deinum]

Spring only invokes private constructors, allt he other things (private properties, methods) can be invoked but you willh ave to do some work (configuration) for that.

Spring uses reflection to invoke all methods/constructors and with reflection well you can basically do everything. Also it is not only spring how do you thing the @Resource on private fields in EJB3 work!

This means that there is nothing private in spring application and we cannot ensure the safety of any property.

Basically, given the ejb fact, it means nothing in a java EE application can be ensured...

[howitzer]

It can also be argued that Spring's influence over the Bean LifeCycle is during bean creation/initialisation and the bean's destruction.

At initialisation time it is fair to say that by one way or another the initial values of beans need to be set for the application to achieve the desired functionality. Spring simplifies this for us. Once the beans start interacting with each other, as Marten has pointed out, mechanisms like reflection, aspects and proxies have to be used to interfere with abstraction. POJOs can't influence abstraction.

So the 'violation' of the abstraction has to be pretty intentional and all Spring does is facilitate these intentions.

As such this is all pretty advanced programming and requires one to know what they are doing.