45

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?

Raedwald
  • 46,613
  • 43
  • 151
  • 237
athena
  • 5,579
  • 8
  • 30
  • 31
  • Why do you expect to get a warning on this? Did you read somewhere that JVM will do this for you? – Cratylus Sep 05 '10 at 13:01
  • 1
    The sort of problem is very easy for the developer to detect and first. The JVM tends to warn a bout problems you cannot detect easily, like a corrupt class file. – Peter Lawrey Sep 05 '10 at 14:31
  • 1
    I love how only 2 of the 5 answers (as of the time I write this) really answer your question: `why doesn't the compiler detect and warn about the potential issue`. And neither of those 2 is the highest voted (again, at least at the time I write this). – Bert F Sep 05 '10 at 17:09
  • 1
    @BertF: seven years later, still true. – Olivier Cailloux Mar 27 '18 at 14:36
  • Who selected the accepted answer then? – Nery Ortez Jul 14 '18 at 13:01

5 Answers5

44

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);
user987339
  • 10,519
  • 8
  • 40
  • 45
Vivien Barousse
  • 20,555
  • 2
  • 63
  • 64
  • 8
    But aren't circular dependencies bad? If you actually have circular dependencies in the code (like the example you gave), isn't it an indicator of bad design? If yes, then why does java support it? If not, then can you point me to some cases where design involving circular dependency is preferred? – athena Sep 05 '10 at 16:05
  • 1
    How about producer/consumer or any callback/event situation? Something like this will end up happening, though probably not literally depending between two classes. Maybe interfaces. – Domingo Ignacio Sep 05 '10 at 16:27
  • 2
    It's not really clear what 'dependency' means in this case. Dependency is often translating to `X` needs to *happen* before `Y`. – Andre Holzner Sep 05 '10 at 16:30
  • 11
    To give a real life example: You could for example rename `A` to `Parent` and `B` to `Child`. Such relations occur frequently in computing (the `Parent` class needs to know how it's child is and the `Child` class needs to know who the `Parent` is), e.g. when working with XML documents (child tags are enclosed in parent tags etc.) – Andre Holzner Sep 05 '10 at 16:33
  • 2
    This does not answer the question (about why the problem is not detected before runtime by adequate tools). – Olivier Cailloux Mar 27 '18 at 14:35
  • 1
    @OlivierCailloux though it seems obvious in this case, detecting stack overflow is undecidable in general. – setholopolus Dec 05 '19 at 20:42
  • To give _more_ real life examples... `String` has a dependency on `Integer` (`String.valueOf(int i)` uses `Integer.toString(i);`); and `Integer` depends on `String` (it has a bunch of `toString` methods). Sometimes this is inevitable in code, although yes, avoiding it _wherever sensible to do so_ or _wherever having one may cause an issue_ is a good idea. – BeUndead Feb 10 '20 at 16:58
21

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.

Michael Barker
  • 14,153
  • 4
  • 48
  • 55
12

It isn't necessarily as easy as in your example. I believe solving this problem would be equal to solving the halting problem which -- as we all know -- is impossible.

musiKk
  • 14,751
  • 4
  • 55
  • 82
  • I agree, determining whether there is a circular dependency for complex cases might not be feasible. But, we can approximate, in which case the JVM might just indicate that there is a potential circular dependency. The developer can then review the code. – athena Sep 05 '10 at 16:10
  • I'd think that most cases a compiler could detect by approximation __in reasonable time__ are those that jump right at you (like the example in your question). Having this as a requirement would make writing the compilers very difficult while gaining little. – musiKk Sep 05 '10 at 16:39
  • 1
    The JVM is approximating this test, via the stack limit. A more robust execution model with an endless stack would simply fail to halt; stack frame limitations are a desirable mechanism for finding exactly this kind of problem. I would argue that you will almost never encounter a stack overflow that isn't a circular dependency. – Mark McKenna Oct 05 '11 at 16:23
5

If you really have a use case like this, you could create the objects on demand (lazily) and use a getter:

public class B 
{
    private A a;

    public B()
    {
        System.out.println("Creating B");
    }

    public A getA()
    {
      if (a == null)
        a = new A();

      return a;
    }
}

(and similarly for the class A). So only the necessary objects are created if when you e.g. do:

a.getB().getA().getB().getA()
Andre Holzner
  • 18,333
  • 6
  • 54
  • 63
1

A similar workaround to getters/setters using composition and and constructor injection for the dependencies. The big thing to note is that the objects don't create the instance to the other classes, they are passed in (aka injection).

public interface A {}
public interface B {}

public class AProxy implements A {
    private A delegate;

    public void setDelegate(A a) {
        delegate = a;
    }

    // Any implementation methods delegate to 'delegate'
    // public void doStuff() { delegate.doStuff() }
}

public class AImpl implements A {
    private final B b;

    AImpl(B b) {
        this.b = b;
    }
}

public class BImpl implements B {
    private final A a;

    BImpl(A a) {
        this.a = a;
    }
}

public static void main(String[] args) {
    A proxy = new AProxy();
    B b = new BImpl(proxy);
    A a = new AImpl(b);
    proxy.setDelegate(a);
}
gpampara
  • 11,989
  • 3
  • 27
  • 26
  • I don't see how this solves the problem, since you are relying on the implementor of B to not call any methods on A in B's constructor when A is injected. Doing so would cause the method invocation to occur on the proxy, which would ultimately result in a NullPointerException since you'd like proxy those calls on the A (which would be null). – marchaos May 11 '12 at 13:35
  • The same can be said for the getter/setter case. The point here is that to create an instance, a parameter must be passed to the constructor. The proxy instance here allows for a "late binding" which breaks the circular dependency. Is it clean? No. Is it a viable solution? Yes, in the short term but definitely not in the long term. The correct solution would be a better design where A and B are oblivious to each other. eg: C c = new C(A, B) – gpampara May 14 '12 at 05:37