views:

172

answers:

5

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?

+7  A: 

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
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
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
+8  A: 

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);
Vivien Barousse
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
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 Galdos
It's not really clear what 'dependency' means in this case. Dependency is often translating to `X` needs to *happen* before `Y`.
Andre Holzner
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
+6  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.

Michael Barker
A: 

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
A: 

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