Community
Participate
Working Groups
Via right-click in the Outline view, I searched for references to the class HashKey and its constructor. This class is nested within org.eclipse.draw2d.AutomaticRouter. I used the search scope Workspace. The search results came up empty for both searches (class and constructor), even though HashKey is referenced many times within the AutomaticRouter. I assume that something is wrong with the search algorithm.
Where is org.eclipse.draw2d.AutomaticRouter defined ?
It is in the Draw2D part of the GEF (Graphical Editor Framework).
When indexing AutomaticRouter.class, BinaryIndexer doesn't add a typeRef to HashKey, but to AutomaticRouter$HashKey. I think we should have both: a typeRef to HashKey and a typeRef to AutomaticRouter$HashKey (it could be a ref to a top-level class). The drawback is that we're going to increase the size of the index even if the latter almost never happens. Kent, what do you think?
I think we should only record simple name refs (such as 'AutomaticRouter' and 'HashKey') in the index, not refs to A$B names. Then the BinaryIndexer would breakup the type signature names into their simple parts to match. Verifying a match against a .class should be much faster than having to parse a source file.
So how would we find references to A$B where A$B is a top-level type?
A$B as a top-level typename is strongly discouraged... so I don't 'care' if we support it or not. Maybe we should but not at the expense of member type references from .class files. I think the 'bug' is in the BinaryIndexer since it doesn't convert p1/A$B into p1.A.B.
Overrode addTypeReference(...) in BinaryIndexer to replace '$' with '.'.
Verified.
