Community
Participate
Working Groups
I have a public constructor used in 2-3 places. It is the sole constructor for the class and takes about 16 arguments. When I select the constructor name, and F3 or search/references/workspace, it lists the references to the constructor among a raft of references to the class, all as inexact. I just switched from R2.0 to 2.1M4 this morning, and I'm pretty sure this was not the behavior under R2.0.
Same problem with an int field of an inner class. Search revealed the matches as inexact, even though they should have been exact.
We had a couple regressions in M4, on the way to address more negative scenarii (cases where the method isn't visible, but you still have a reference onto it). Could you try to reproduce with the latest integration build, and if it still occurs, then please provide a test case reproducing it.
The problem continues to occur *consistently* in my project, even with I20030129. When I tried to replicate the problem in another project, I could not reproduce the problem. However it did expose a different problem: I remember a dialog box telling me it only found inexact matches, and offering me a check box to not show that dialog again. Since the system was *only* showing me inexact matches at the time (even when they should have been exact), on one of the iterations, I checked the box. When I attempted to provoke the bug with a toy project, it showed me both the exact and inexact matches. (I didn't realize it would show both, actually.) I can find nothing in the preferences to revoke my previous choice, but maybe I'm just not familiar with the right setting. This has effectively made search useless for me ... can't find the needle among all the straw. Here is test code I used which shows the second problem, but not the first: package buildI20030129; public interface Foo { public Bar bar(); } package buildI20030129; public interface Bar { public void create(); } package buildI20030129; public class Baz { public static void main(String argv[]) { Foo foo = null; foo.bar().create(); } } Select "create" in Baz.java and CTRL-SHIFT-G. I get 17 inexact matches along with the 1 real one, mostly coming from libraries. Because M4 and I20030129 are wedging on my box (see bug #30546), it's taken me more than an hour to prepare the above, and I can't throw any more time at it for the moment. HTH.
Bug is still present in 2.1RC1. Extremely irritating. Makes some common method names nearly unsearchable. Changed summary to reflect broad nature of this bug.
Eric, it looks like your libraries are inconsistent, i.e. if you expand the attached source in a folder and replace the library entries on the build path with the attached source folder, does it compile ok? If you have compile errors (like missing types) it is most likely that matches will be reported as inexact.
Jerome, Your message didn't even *begin* to make sense. What libraries do you suspect are inconsistent and in what way? What "attached source" are you referring to? For the record, I consistently get inexact matches on all searches even when I have no compile errors or warnings anywhere in the project. This is behavior that was introduced since R2.0 and has persisted through 2.1RC1. In a smaller project (same workspace) I get both exact and inexact matches. (But why are the exact matches not placed at the beginning of the list?) This nearly-correct behavior is present in most of my projects in this workspace. But in the main project I'm working on, I consistently get inexact matches which ought to be exact. Example 1: public class Util { public static Util singleton() { return singleton; } ... } Searching on singleton (i.e. selecting singleton and CTRL-SHFT-g) brings up all inexact matches, including leftComp.setFont(Util.singleton().getSmallFont()); and public MBoxStore() { super(Util.singleton().getSession(), null); } This is not limited to static methods... public interface IMEDB extends IMEDBConstants{ // ----- thrasks public ThraskAccessor thrask(); public SavedThraskAccessor savedThrask(); public ThraskAccessorBase thrask(boolean saved); ... } Searching on "thrask" generates all inexact matches including... public class TMDBSetupTestCase extends TestCase { protected IMEDB db; ... private void checkUnreadCount(int[] countArrayForThrasks) { int i,ct; for (i=0; i<countArrayForThrasks.length;++i) { ct=db.thrask().getUnreadCount(dlMap.mapThrask(i+1)); assertEquals("thrask count:"+(i+1), countArrayForThrasks[i], ct); } } The "thrask()" in "ct=db.thrask(). ..." is shown is inexact.
Sorry, if it didn't make sense. I'm wild guessing here. The best would be to get your workspace to see what's wrong. If you cannot give us the workspace, then we need accurate steps to reproduce the problem. Nobody else as reported such a problem lately.
Fwiw, I am no longer seeing these problems in R2.1.
Since Eric is not seeing the problem any longer, I'm closing this bug. Anyone, please reopen if you see the problem again (in 2.1 or later) and if you have steps to reproduce it.
