Bug 101019 - RC3: Type Hierarchy does not find implementers/extenders of inner class/interface in other project
Summary: RC3: Type Hierarchy does not find implementers/extenders of inner class/inter...
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.1   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.1 RC4   Edit
Assignee: Jerome Lanneluc CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-06-21 06:50 EDT by Erwin Tratar CLA
Modified: 2005-06-24 07:44 EDT (History)
2 users (show)

See Also:


Attachments
Proposed patch (788 bytes, patch)
2005-06-21 13:43 EDT, Jerome Lanneluc CLA
no flags Details | Diff
Regression test (2.49 KB, patch)
2005-06-22 10:12 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 Erwin Tratar CLA 2005-06-21 06:50:13 EDT
Suppose you have:

Project A:
public class Foo {
 public interface BaseIf {}
 public static class Base {}
}

public class Bar extends Foo.Base implements Foo.BaseIf {}

Project B (with dependency on A):
public class OtherBar extends Foo.Base implements Foo.BaseIf {}

and you open a Type Hierarchy on Foo.BaseIf or Foo.Base, only the Bar is found,
not OtherBar.
Comment 1 Erwin Tratar CLA 2005-06-21 07:05:24 EDT
in fact, a Java Search for Implementors has the same problem
Comment 2 Frederic Fusier CLA 2005-06-21 07:48:28 EDT
I don't agree with comment 1.
Search for implementors of Foo.BaseIf in Workpsace returns correctly 2 matches:
one in project A and one in project B.
Search returns only one match if you perform it in Project scope which is the
expected behavior...
Comment 3 Erwin Tratar CLA 2005-06-21 07:59:30 EDT
you're right. I tried it with Base only, which is not an interface. I was
mislead in believing it could also find subclasses, but the documentation cleary
states it finds implementors of interfaces only. my bad, just forget comment #1
Comment 4 Jerome Lanneluc CLA 2005-06-21 13:43:13 EDT
Note this is a regression comparing to 3.0
Comment 5 Jerome Lanneluc CLA 2005-06-21 13:43:45 EDT
Created attachment 23648 [details]
Proposed patch
Comment 6 Philipe Mulet CLA 2005-06-21 14:13:24 EDT
Given this is a regression, and fix is somewhat trivial, we should address it.
Note this is not 1.5 specific.

Dirk - can you vote for it ?
Comment 7 Philipe Mulet CLA 2005-06-21 14:13:44 EDT
Dani - can you vote for it ?
Comment 8 Dani Megert CLA 2005-06-21 15:12:25 EDT
The fix seems rather simple. Can you explain what caused this regression?
Comment 9 Dirk Baeumer CLA 2005-06-22 03:25:44 EDT
+1 for RC3.
Comment 10 Dirk Baeumer CLA 2005-06-22 03:26:18 EDT
RC4 of course.
Comment 11 Jerome Lanneluc CLA 2005-06-22 05:43:59 EDT
(In reply to comment #8)
> The fix seems rather simple. Can you explain what caused this regression?

The regression was introduced on 10/14/2004 (revision 1.72 of NameLookup.java)
when working on performance. The method NameLookup#seekTypesInSourcePackage(...)
was re-written and '.' was used as the member type separator instead of '$'.
This broke the contract of INameEnvironment#findType(...) that says that member
types should be found using a '$' name.
Comment 12 Dani Megert CLA 2005-06-22 05:46:12 EDT
+1 for 3.1 RC4 then.
Comment 13 Jerome Lanneluc CLA 2005-06-22 10:12:01 EDT
Created attachment 23731 [details]
Regression test
Comment 14 Jerome Lanneluc CLA 2005-06-22 10:46:40 EDT
Released fix and test
Comment 15 Maxime Daniel CLA 2005-06-24 06:15:25 EDT
Verified for Build id: I20050624-0010.
Comment 16 Olivier Thomann CLA 2005-06-24 07:44:42 EDT
Verified.