Bug 59843 - Eclipse 3.0M8 generates ambiguous keys from ITypeBindings for nested classes with the same name
Summary: Eclipse 3.0M8 generates ambiguous keys from ITypeBindings for nested classes ...
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.0   Edit
Hardware: PC Windows 2000
: P3 normal (vote)
Target Milestone: 3.0 M9   Edit
Assignee: Olivier Thomann CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-04-23 16:23 EDT by Edwin Chan CLA
Modified: 2004-05-18 11:41 EDT (History)
0 users

See Also:

Attachments
testKeys plugin project (6.76 KB, application/x-zip-compressed)
2004-04-23 16:24 EDT, Edwin Chan CLA 		no flags Details
TestClassesWithSameName (6.43 KB, application/x-zip-compressed)
2004-04-23 16:24 EDT, Edwin Chan CLA 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Edwin Chan CLA 2004-04-23 16:23:30 EDT 
The problem is that the String keys returned by ITypeBinding.getKey don't seem
to include the name of the outer class.  This generally is not a problem, except
in the case that we have multiple classes with the same name in the same package.
In the TestClassesWithSameName project, we have a normal class Test, along with
several nested classes called Test, yet they all have the same key.

I've included a testKeys project which is designed to be run as a plugin
project, with TestClassesWithSameName in the run-time workspace.
Comment 1 Edwin Chan CLA 2004-04-23 16:24:06 EDT 
Created attachment 9914 [details]
testKeys plugin project
Comment 2 Edwin Chan CLA 2004-04-23 16:24:37 EDT 
Created attachment 9915 [details]
TestClassesWithSameName
Comment 3 Olivier Thomann CLA 2004-04-23 16:46:50 EDT 
I think replacing getName() with this.binding.constantPoolName() in the getKey()
of a TypeBinding would fix it.
Comment 4 Olivier Thomann CLA 2004-04-26 14:46:41 EDT 
Using the constant pool name, it returns:
test0545/First$Test
test0545/Second$Test
test0545/Third$Test
test0545/Test


I think this is the expected answer according to the comment on IBinding.getKey().
Comment 5 Olivier Thomann CLA 2004-04-26 14:54:23 EDT 
Fixed and released in HEAD.
Regression test added.
Comment 6 David Audel CLA 2004-05-18 11:41:01 EDT 
Verified for 3.0M9