greg4cr/coupling-mapping

A utility for mapping dependencies between Java projects.

coupling-mapping's Issues

Need to restore currentClass to name of outer class after finished parsing inner classes

See title

Expressions in constructor arguments interpreted incorrectly

X y = new X (z.length);
z.length is thought of as being part of class X.

This is due to the changes introduced to fix issue #4

Investigate strange results

Some that stand out:
newStringBuilder.append.append.append.append.append.append.append'.toString
(the character mark)

newCompareToBuilder.append,other.getLeft.append,other.getMiddle.append,other.getRight.toComparison
(comma-sep list, think a "new" might be getting merged in)

Look over next week.

Parentheses not handled correctly

For example:
(new BigDecimal(Double.toString(x)).setScale(scale,roundingMethod)).doubleValue

There is a "." inside the parentheses (the .setScale). Currently, expressions assume that segments (between ".") are independent (unless they are arguments). Need to adjust how these expressions are handled.

Non-static inner classes should be able to reference methods of outer class

See title. Currently, an inner class that references methods from the outer class results in an unresolved coupling (i.e., 'escapeRegex.append').

Need to handle "this" properly in coupling list

Need to filter out "this" on the Type/var replace.

Ternary expressions need filtered

Ternary expressions with couplings are placed in the coupling list. Everything before the "." is considered the be the variable name:

Coupled to non-project class: value==1?iSingularText:iPluralText.length

These get caught and removed, and the actual coupling ('iPluralText.length') is caught, so there is no effect on the end results. Still, these should be filtered out to prevent confusion.

Anonymous classes should be able to use variables from the outer class

See:

@Override
        public Iterator<Entry> iterator() {
            final Iterator<Entry> i = v.iterator();
            return new Iterator<Entry>() {
                /** The current entry. */
                private final UnmodifiableEntry e = new UnmodifiableEntry();

                /** {@inheritDoc} */
                public boolean hasNext() {
                    return i.hasNext();
                }

                /** {@inheritDoc} */
                public Entry next() {
                    e.setIndex(i.next().getIndex());
                    return e;
                }

                /**
                 * {@inheritDoc}
                 *
                 * @throws MathUnsupportedOperationException in all
                 * circumstances.
                 */
                public void remove() throws MathUnsupportedOperationException {
                    throw new MathUnsupportedOperationException();
                }
            };
        }

The nested class refers to variable i. Currently, we can't see "i", as the parent of the anonymous class is "Iterator".

Anonymous classes not captured correctly

When there is an embedded class, i.e.:

private static final ToStringStyle TO_STRING_STYLE = new ToStringStyle() {
    ...
}

Couplings are captured as though they are part of the outer class.

For instance, super.appendDetail stays the same, as the outer class has no parent.

Handling items in List classes

When dealing with List classes, we get couplings that look like:

List<X>.get.getInterpolatedSecondaryState

However, the type we're dealing with is clearly not List, but X. On one hand, we can't always make this assumption, as we lack info on the inner-workings of non-project classes. On the other, we can make assumptions about known concrete List types from Java. Should we keep a list of those and override the current logic if such as class applies?

Anonymous class names

When compiled, these appear as Parent$1, Parent$2, etc. Rename these to match.

Class-level couplings can be grouped with local-level couplings

If class variables are defined after a method, i.e.:

void test(){
...
}

x = y.z();

The coupling to y.z() will be labeled as being part of test().