Bug 249567 - Incorrect behavior of Util.getUnresolvedJavaElement(...) method
Summary: Incorrect behavior of Util.getUnresolvedJavaElement(...) method
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.4   Edit
Hardware: PC Windows XP
: P3 normal with 1 vote (vote)
Target Milestone: 3.5 M3   Edit
Assignee: Jerome Lanneluc CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-10-03 01:37 EDT by Dmitriy Matveev CLA
Modified: 2008-10-28 12:01 EDT (History)
1 user (show)

See Also:


Attachments
Proposed fix and regression test (3.26 KB, patch)
2008-10-13 13:07 EDT, Jerome Lanneluc CLA
no flags Details | Diff
Improved fix and more tests (6.56 KB, patch)
2008-10-14 08:58 EDT, Jerome Lanneluc CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Dmitriy Matveev CLA 2008-10-03 01:37:58 EDT
There are two classes in different packages, but with equal names in that packages. package1.MyClass and package2.MyClass (they can be empty)
There one class with two fields of that types and two constructors taking single argument of one of these types.
Class with parsing problem:

public class MixedMethods
{
    private final package1.MyClass _fieldFromPackage1;
    private final package2.MyClass _fieldFromPackage2;

    MixedMethods(package2.MyClass o)
    {
        _fieldFromPackage1 = null;
        _fieldFromPackage2 = o;
    }

    MixedMethods(package1.MyClass o)
    {
        _fieldFromPackage1 = o;
        _fieldFromPackage2 = null;
    }
}

Type declaration node contain following children:

0: private final cfg.package1.MyClass _fieldFromPackage1;
1: private final cfg.package2.MyClass _fieldFromPackage2;
2: MixedMethods(cfg.package2.MyClass o){
  _fieldFromPackage1=null;
  _fieldFromPackage2=o;
}
3: MixedMethods(cfg.package1.MyClass o){
  _fieldFromPackage1=o;
  _fieldFromPackage2=null;
}

Our parse procedure is following:
1. Take methodBinding via IMethodBinding.resolveBinding() method.
2. Replace it by call to getMethodDeclaration() on it.
3. Invoke getJavaElement() method on it to get IMethod.

The 3rd action leads us inside Util.getUnresolvedJavaElement(MethodBinding, WorkingCopyOwner, BindingToNodesMap) method where correct IMethod is created and then similar method search is performed. findMethods member returns both constructors as similar methods and first of them is used, so we have incorrect IMethod for node with index 3. That happens because search procedure uses areSimilarMethods which performes method comparison by simple names instead of qully-qualified ones.
Comment 1 Jerome Lanneluc CLA 2008-10-13 13:07:39 EDT
Created attachment 114960 [details]
Proposed fix and regression test
Comment 2 Jerome Lanneluc CLA 2008-10-14 08:58:30 EDT
Created attachment 115025 [details]
Improved fix and more tests
Comment 3 Jerome Lanneluc CLA 2008-10-14 09:48:44 EDT
Fix and tests released for 3.5M3.

(Note to verify that the fix is in, one can run the tests with and without the fix)
Comment 4 David Audel CLA 2008-10-28 12:01:10 EDT
Verified for 3.5M3 using I20081026-2000 build.