This week's book giveaway is in the OCPJP forum. We're giving away four copies of OCA/OCP Java SE 7 Programmer I & II Study Guide and have Kathy Sierra & Bert Bates on-line! See this thread for details.
While discussing with my friends i came to know regardng the Circular Redundancy concept: Basically what i heard was that if there are 2 classes A & B both in diff packages and both referencing each other it would cause the JVM to hang.
I tried this out and it worked fine for me. Could anybody confirm if i have understood the concept correctly? If not please could you guide me regarding this?
Could it be possible that this was an issue in earlier versions of java and is not an issue now?
I searched in google i came up with many links but none was explaining the concept and its consequences sufficiently.
Thanks a lot for replying to this. Yes i meant circular dependency, thanks for correcting me. However there are a few discussions on net concerning circular dependency and how we should avoid them using interfaces.
My question is if its not an issue why are we trying to avoid it?
It's not an issue in the sense that it will not cause the JVM to hang. But there are other problems with it.
For example, suppose that you have a class A that depends on class B, and B also depends on A. How are you going to compile those classes? To compile A, you need to compile B first, but to compile B, you need to compile A first. Maybe the Java compiler can figure that problem out if you pass both files to the compiler at the same time. But it won't be possible to compile them separately.
Besides the practical problems, having a circular dependency is also a sign that there is a problem with the design of your program. It is an indication that the classes A and B are too much tangled up with each other (they violate the princple of separation of concerns); their functionality cannot be separated. It's a sign that A and B should probably be combined in a single class, or that the functionality should be split in a different way.
May be I am wrong but your problem seems to be mixed up..... with Circular Redundancy and Circular Dependancy
Circular Dependancy can cause errors like StackOverlowException.
and Circular Redundancy is the hardware problem which can cause your system to hang.
Ankit Datt Gaur
Joined: Nov 28, 2011
I mean Circular Dependency only. I fully agree with Jesper's explanation that the scenario mentioned by me would not compile and also exhibits tight coupling.
Could you please explain to me how the circular dependency can cause StackOverflow? This was what i wanted to know. because i made two classes referrencing each other and compiled them together and they are running fine.
Here is an example where you would get a StackOverflowError. When you create an instance of A, it creates an instance of B, which again creates an instance of A, which again creates an instance of B... until the stack overflows.
Ankit Datt Gaur
Joined: Nov 28, 2011
Thanks a lot for explaining this. I would change the staus to Resolved now as i think i have got teh answer to what i was asking.
Jesper de Jong wrote:Here is an example where you would get a StackOverflowError. When you create an instance of A, it creates an instance of B, which again creates an instance of A, which again creates an instance of B... until the stack overflows.
Jesper - this is circular dependency or redundancy...
And as for compilation problem mentioned in one of the earlier comments, it can be tackled easily by first creating blank, skeleton classes. Something like:
Once these 2 classes are compiled, you are free to refer either of them in the other one, without getting compiler irritated. Later, you can start putting members (fields, methods etc.) in these classes (and using them in the other class) as required.
While this definitely is an example of hard-coupling, but the problem of hard-coupling has nothing to do with the circular dependency issue. Hard-coupling will still exist if only one class referred to another, and not the vice-versa. How to resolve that is a completely separate topic.