Circular dependency in Java constructors
I have the following classes.
public class B
{
public A a;
public B()
{
a= new A();
System.out.println("Creating B");
}
}
and
public class A
{
public B b;
public A()
{
b = new B();
System.out.println("Creating A");
}
public static void main(String[] args)
{
A a = new A();
}
}
As can be clearly seen, there is a circular dependency between the classes. if I try to run class A, I eventually get a StackOverflowError
.
If a dependency graph is created, where nodes are classes, then this dependency can be easily identified (at least for graphs with few nodes). Then why does the JVM not identify this, at least at runtime? Instead of a throwing StackOverflowError
, JVM can at least give a warning before starting execution.
[Update] Some languages cannot have circular dependencies, because then the source code will not build. For example, see this question and the accepted answer. If circular dependency is a design smell for C# then why is it not for Java? Only because Java can(compile code with circular dependencies)?
[update2] Recently found jCarder. According to the website, it finds potential deadlocks by dynamically instrumenting Java byte codes and looking for cycles in the object graph. Can anyone explain how does the tool find the cycles?
Solution 1:
The constructor of your class A calls the constructor of class B. The constructor of class B calls the constructor of class A. You have an infinite recursion call, that's why you end up having a StackOverflowError
.
Java supports having circular dependencies between classes, the problem here is only related to constructors calling each others.
You can try with something like:
A a = new A();
B b = new B();
a.setB(b);
b.setA(a);
Solution 2:
Its perfectly valid in Java to have a circular relationship between 2 classes (although questions could be asked about the design), however in your case you have the unusual action of each instance creating an instance of the other in its constructor (this being the actual cause of the StackOverflowError).
This particular pattern is known a mutual recursion where you have 2 methods A and B (a constructor is mostly just a special case of a method) and A calls B and B calls A. Detecting an infinitely loop in the relationship between these 2 methods is possible in the trivial case (the one you've supplied), but solving it for the general is akin the solving the halting problem. Given that solving the halting problem is impossible, compliers generally don't bother trying even for the simple cases.
It might be possible to cover a few of simple cases using a FindBugs pattern, but it would not be correct for all cases.