#492 New Test: Shadowing a field

[Benoit Xhenseval]

Hi *,

I would like to suggest a new test to detect the following basic pattern.
I believe that in most case this is a bug (especially after a big re-factoring).

Both TestA and TestB define methods get/setField, which is fine but they also define
the field itself. This is unlikely to be correct.

I'd love to see this test added to the tool

Thanks for considering it

Regards from London,

Benoit

public class TestA {
private int field;

public int getField() {
    return field;
}

public void setField(int field) {
    this.field = field;
}

}

public class TestB extends TestA {
private int field; // should be flagged!

@Override
public int getField() {
    return field;
}

@Override
public void setField(int field) {
    this.field = field;
}

}

[Ryan Gustafson]

Logged In: YES
user_id=342470
Originator: NO

This example is strange. How can TestB override the methods on TestA, and not have it's own field of some sort? TestA.field is declared private, and TestB's implementation is not calling super.getField().

Is the intent of the rule to state there is a trivial override occurring in a subclass? E.g. no extra behavior beyond that already defined in the super class?

We already catch calls to just super.method(). Verifying the implementation is distinctly different is another matter entirely, requiring parsing of multiple source files at the same time, something PMD does not currently do. That's assuming we even have the code for TestA available, it might be a super class which exists in some JAR alone.