#1 exclude not authoritive

[Carsten Heyl]

Hi!

Combined with structure101 classycle is great software for reducing class/package cycles.
Thanks for providing that!
When starting to reduce cycles it's often necessary to
exclude some classes because they are known to produce cycles but can't be done yet.
So I tried to use the exclude feature of classycle but failed.
The problem: classcycle may later automatically re-add those classes if it encounters dependancies on them.
I fixed that for myself by not allowing classes from our
packages to be added automatically but thats obviously only valid for us here and today.
They should only be added if not in the exclude list.

The idea of "best fragmenters" is really great and helped me a lot to find the major cycle hots spots while analyzing class cycles.
But when moving to package cycles it was great to see what packages are best fragmenters but I wondered if it would be usefull to have best fragmenter classes on package level, tool.
Inspired by classycle and using it's dependency output as
input I did some jgrapht programming and found it really helpful.
More often than not only a few classes of a package cause the package cycles and could be identified.

What I did:
1. Take the best and next best fragmenters of package cycles.
2. For each class of each best package fragmenters check how much it reduces the package cycle.

By including the next best package fragmenters I found this algorithm to find fragmenter classes at a rate clearly above 50%.
I thought about adding a test if moving the class to another existing package would help but than did that by hand using structure101 to view the deps.

At some point in time it would have been helpful for me if classycle could dump the dependancies as XML and be able to read those file to calculate the dependancies based on the file.
This would allow "virtual refactorings" (move class) by moving classes by renaming their package names in the xml
and applying classycle to the virtual class deps.
But since classycle did the hard work of reading and analyzing the classes and providing the data as xml and jgrapht does provide the graph utilities it was suprisingly simple to rewrite the classycle cycle analyzer.
Just a matter of reading the detailed classycle docs (thanks!), a few lines of xsl to extract the deps from xml, a simple vertex/edge reader and some jgrapht magic.
Makes be feel like standig on the shoulders of giants ...

So enough for today, keep going!

Greeeetings,

Carsten

[Franz-Josef Elmer]

Logged In: YES
user_id=245851
Originator: NO

Hi Carsten

You wrote:

When starting to reduce cycles it's often necessary to exclude
some classes because they are known to produce cycles but can't
be done yet. So I tried to use the exclude feature of classycle
but failed.

I couldn't reproduce this bug with version 1.3.1. I've tried the following as an example:

java -jar classycle.jar -mergeInnerClasses -excludingClasses=classycle.classfile.Constant -xmlFile=analysis-example.xml classycle.jar

Excluding the class Constant removes the cycle where Constant was its best fragmenter. It appears in the list 'Uses external' of all classes referring Constant (like DoubleConstant).

Please, can you provide me an example which shows this bug clearly.

Regards
Franz-Josef

[Carsten Heyl]

Logged In: YES
user_id=184317
Originator: YES

Hi!

Sorry, I tried for more than 4 hours to reproduce what I had 2 weeks ago but couldn't reproduce excactly what I remembered.
I did the work on a 7000+ class project and it wasn't easy to see exact causes of problems.
There are a few oddities and a bug I found on the way:
- when the first reference to a package is via an excluded class an "unknown class" vertex is generated as an external ref but
that seems to make the whole package "external" so it is not used in caclculating package cycles
- excluding classes excludes "class files" but not "class entities" where class entity includes merged inner classes. That may
made be believe that my exclude is ignored. It guess changing the pattern to include inner classes would work but IMHO inner
classes should be macthed by the exclude patterns especially if mergeInnerClasses is set.

My "brute force work around hack" suppressed external refs to ignored classes so I got around the first case.
The second can be probably be fixed by widening the exclude pattern but I fixed the cacle I had and removed the exclude entry.

It's difficult for me to extract test cases but when a new (cvs) version of classycle is available I can run it against our current and older code base for testing.

Greetings,
Carsten

[Franz-Josef Elmer]

Logged In: YES
user_id=245851
Originator: NO

Hi Carsten

By preparing a simple example I also found strange results. I'll working on it.

Franz-Josef

[Franz-Josef Elmer]

Logged In: YES
user_id=245851
Originator: NO

Hi Carsten

I found two bugs in PackageProcessor.

1. A package vertex is an external vertex if all its class vertices are external. The code assumes that either all or non of the class vertices are external. But because of excluding a single class a package vertex can have both external and internal class vertices.

2. In traversing the class graph an arc from a class vertex to another class vertex yields an arc between the corresponding package vertices. Now if the head vertex of this arc is an external (or exceluded) class vertex the correpronding arc in the package graph should only be drawn if it is an arc to an external package. Otherwise package cycles cannot be broken by excluding a class causing the cycle.

I have fixed these two bugs in PackageProcessor. Please, can you try it before I will making a new release of Classycle.