Menu
What tool would you recommend to detect Java package cyclic dependencies, knowing that the goal is to list explicitly the specific classes involved in the detected 'across-packages cycle'?
I know about classycle and JDepend, but they both fail to list the classes involved in a cyclic package dependency. Metrics has an interesting graphical representation of cycles, but it is again limited to packages, and quite difficult to read sometime.
I am getting tired to get a:
" you have a package cycle dependency between those 3 packages
you have xxx classes in each
good luck finding the right classes and break this cycle "
Do you know any tool that takes the extra step to actually explain to you why the cycle is detected (i.e. 'list the involved classes')?
Riiight... Time to proclaim the results:
@l7010.de: Thank you for the effort. I will vote you up (when I will have enough rep), especially for the 'CAP' answer... but CAP is dead in the water and no longer compatible with my Eclipse 3.4. The rest is commercial and I look only for freeware.
@daniel6651: Thank you but, as said, freeware only (sorry to not have mentioned it in the first place).
@izb as a frequent user of findbugs (using the latest 1.3.5 right now), I am one click away to accept your answer... if you could explain to me what option there is to activate for findbug to detect any cycle. That feature is only mentioned for the 0.8.7 version in passing (look for 'New Style detector to find circular dependencies between classes'), and I am not able to test it. Update: It works now, and I had an old findbugs configuration file in which that option was not activated. I still like CAD though ;)
THE ANSWER is... see my own (second) answer below
951
Analyze cyclic dependenciesFrom the main menu, select Code | Analyze Code | Cyclic Dependencies. In the Specify Cyclic Dependency Analysis Scope dialog, select the scope of files that you want to analyze. Select the Include test sources option if you want to analyze your test code together with the production code.
There are a couple of options to get rid of circular dependencies. For a longer chain, A -> B -> C -> D -> A , if one of the references is removed (for instance, the D -> A reference), the cyclic reference pattern is broken, as well. For simpler patterns, such as A -> B -> A , refactoring may be necessary.
1) Using packagename.* If you use package.* then all the classes and interfaces of this package will be accessible but not subpackages. The import keyword is used to make the classes and interface of another package accessible to the current package.
Well... after testing DepFinder presented above, it turns out it is great for a quick detection of simple dependencies, but it does not scale well with the number of classes...
So the REAL ACTUAL ANSWER is: CDA - Class Dependency Analyzer
It is fast, up-to-date, easy to use and provides with graphical representation of classes and their circular dependencies. A dream come true ;)
You have to create a workset in which you enter only the directory of your classes (.class) (no need to have a complete classpath)
The option "Detect circular dependencies - ALT-C" works as advertise and does not take 100% of the CPU for hours to analyze my 468 classes.
Note: to refresh a workspace, you need to open it again(!), in order to trigger a new scan of your classes.
191
Findbugs can detect circular class dependencies and has an Eclipse plugin too.
http://findbugs.sourceforge.net/
27
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
