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?
But with a circular dependency, Spring cannot decide which of the beans should be created first since they depend on one another. In these cases, Spring will raise a BeanCurrentlyInCreationException while loading context. It can happen in Spring when using constructor injection.
Both The Elements of Java Style [Vermeulen 2000] and the JPL Java Coding Standard [Havelund 2010] require that the dependency structure of a package must never contain cycles; that is, it must be representable as a directed acyclic graph (DAG).
To resolve circular dependencies: Then there are three strategies you can use: Look for small pieces of code that can be moved from one project to the other. Look for code that both libraries depend on and move that code into a new shared library. Combine projectA and projectB into one library.
To reduce or eliminate circular dependencies, architects must implement loose component coupling and isolate failures. One approach is to use abstraction to break the dependency chain. To do this, you introduce an abstracted service interface that delivers underlying functionality without direct component coupling.
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);
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With