Method correspondence is overly simplistic

[metlos]

Currently the correspondence of methods from the two versions of the API is based purely on the containing type and method name.

This is overly simplistic in presence of overloaded methods where we don't always find the closest match and might report false positives or worse miss API changes altogether.

[metlos]

The situation is not that bad as I originally thought but it is a real problem.

The natural order of methods is based on their erased signature. When 2 methods on the same position in the two element trees are compared for correspondence they are detected as corresponding if their defining type and their name matches. This means that the correspondence is robust against return type changes, parameter type changes and parameter number changes.

But the analysis still can get confused because the natural order is based on alphabetical order of the erased signatures which might cause sub-optimal matches during the comparison of the 2 versions of the APIs.

[metlos]

This has been fixed in the API version 0.4.0 (used by revapi-java-0.5.0 and revapi-maven-plugin-0.3.9).