Community
Participate
Working Groups
Open System.class using Ctrl-Shift-T, select the gc() declaration and use the Find References -> in Workspace menu option. Using my workspace with OCL projects, the search responds with 3 hits in rt.jar, but none from my workspace. Using a file search for gc() gets 13 hits, probably all correct since I don't use gc() in my operation names. Why doesn't find references find references?
Moving to JDT Core.
I can confirm, plain text search returns more hits in my workspace, where I have a mix of plugin projects using different JDK versions. The hits are missing in projects with different JDK version as the one where I've searched for references. Ed, I assume the projects where the call is not found, are setup to use a *different* JDK version as the one you've started the search for. E.g. you search starting from System class from Java 11 JDK, but the projects where the hits are missing are setup to use Java 8 JDK. I see same behavior in 4.15, so not a recent regression. Not sure if it ever worked through all the JDK's installed.
(In reply to Andrey Loskutov from comment #2) > Ed, I assume the projects where the call is not found, are setup to use a > *different* JDK version as the one you've started the search for. Confirmed. I develop Java 8 with a bit of Java 6 and Java 5 legacy but am forced to use Java 11 now that the platform has deviated from LTS. I have Java 5, 8 and 11 JVMs. When I selected Ctrl-Shift-T for System the Java 5 variant tops the list so if I select it the Java 8's variant which my code calls aren't 'references'. Indeed it has probably been long broken; we had a long period of Java stability. The treatment of each Java as distinct seems generally unhelpful, since users are interested in Java not in a context-dependent partial Java. Suggest that an aggregate Java is offered in selectors, with a sub-selection if users really want to know if a version-specific variant is inn use. Similarly for Ctrl-Shift-R it is very unhelpful, to be offered distinct X.class and X.java especially if the wrong one is a recent favourite. I nornally want to open the X that my code can use, not what is hidden. Again a sub-selector could offer *.java/*.class distinction. The current diversity at best clutters the dialog, at worst enables non-functional selections.
(In reply to Ed Willink from comment #3) > Indeed it has probably been long broken I have complained/commented a number of times that Java search is dangerously deficient. Diverse Java versions is now a clear repro. Diverse *.class/*.java may be the next.
Seems very similar to bug 553519.
*** Bug 553519 has been marked as a duplicate of this bug. ***
