Bug 119297 - NameLookup.seekTypesInBinaryPackage might not return the right type
Summary: NameLookup.seekTypesInBinaryPackage might not return the right type
Status: RESOLVED DUPLICATE of bug 102286
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.2   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: JDT-Core-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-12-05 15:05 EST by Olivier Thomann CLA
Modified: 2005-12-06 04:45 EST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Olivier Thomann CLA 2005-12-05 15:05:36 EST
From Eclipse newsgroup,

NameLookup.seekTypesInBinaryPackage retrieves the incorrect type in case the required class has an inner class with the same name.
for example, retrieval of com.x.y may return the IType coresponds to com.x.y$y .
The algorithm is seeks through all the classes in the package. for each class, it checks if the current startsWith ( &! equals, to ignore the class extension) the required type name. If it is, it compares the elementName, which is the "last" class name to the required type name. in case both are identical, testing com.x.y$y will return a match for com.x.y (as the type name starts with y, and the element name equals y).
To easily reproduce, download eltima demo from:
http://www.eltima.com/download/visual-java-library/
Add it to a JavaProject class path, then try to JavaProject.findType("com.eltima.components.ui.g"). You will get back the IType corresponding to "com.eltima.components.ui.g$g" (this is the string returned by getFullyQualifiedName).
Comment 1 Jerome Lanneluc CLA 2005-12-06 04:45:35 EST
Since no build number was provided, I'll assume you're using 3.1.1. Please reopen if you still have the problem with I20051130 or later.

*** This bug has been marked as a duplicate of 102286 ***