Community
Participate
Working Groups
1. In Outline view select java.text.DateFormat.HOUR_OF_DAY0_FIELD 2. Search for References in workspace ==> nothing found Note 1: It finds references in .java files but not in JARs. Note 2: Search for all Occurrences (via search dialog) correctly returns the references
Test Case above is bogus. Replace DateFormat.HOUR_OF_DAY0_FIELD in above test case with JavaCore.ATT_HANDLE_ID
Constants are inlined inside binaries, and thus cannot be found from the classfile themselves (which no longer refer to the searched field). We would have to consider the attached sources, this is not on the plan. Closing
I assumed this reaction BUT: it is not understandable why Search for all occurrences finds the references. If searching for reference is the problem then why don't you search for the occurrences first then subtract the declarations? Try it out for JavaCore.ATT_HANDLE_ID
We can fix this only if we index the attached source. For now, this is a known problem and will have to be documented.
Fixed in builds > 20020701
.
OOPS! Touched the wrong bug. Restoring its state to LATER.
Reopening
Clearing resolution
Unclear we can do any better, easily. Please investigate what would be the impact on the indexes (doubling the index size is not an option).
Deferring, shouldn't have been resurrected at this stage.
Reopening to consider for 3.5
One way to achieve this would be to index the attached source when present (instead of indexing the .class file).
Changing title to better reflect the purpose of this bug.
Created attachment 115133 [details] Fix prototype This patch solves the problem but is not finalized yet: 1) there are still some failing tests while running RunJavaSearchTests... 2) the way to get sources in AddJarFileToIndex assumes that files are in a peculiar order in the jar. May be this should be changed to get rid of this assumption... 3) most important point: the time to index jar files with attached sources is 8 times longer than while indexing only the binaries!
Created attachment 115139 [details] New patch prototype Fix issue while running performance tests which highlight the big regression...
Created attachment 115140 [details] New patch prototype Ooops, I forgot to include changes on o.e.jdt.core.tests.model in previous patch...
Created attachment 115157 [details] New prototype This ensures that the Java model is not populated just to read the source name attribute in the .class file
Created attachment 115271 [details] Support for queues with different priorities in JobManager/IndexManager
Created attachment 115273 [details] New prototype merged with new support for queues This prototype fixes comment 16 point 2) and includes the support for queues with different priorities in JobManager/IndexManager added by Jerome. It also adds 2 new tests in JavaSearchBugTests, so added tests now cover the following scenarios: 1) jar file with sources inside 2) jar file with source in a another zip file 3) jar file with source in a folder These 3 scenarios are now supported by this patch, but there are still several failures (28) while running RunJavaSearchTests, hence it's still a prototype...
Deferring to M4
Created attachment 116951 [details] Patch proposed for 3.5M3 This patch passed all JDT tests but was not released into M3 as its design didn't receive the agreement of all reviewers... The proposed design alternative would be to keep one queue for the indexing but have a master switch (likely a preference) to explicitly enrich the indexes with attached sources. So, we still need to decide which design will be used to address this issue...
Created attachment 118501 [details] Last patch updated on top of v_925 Finally, no real agreement was possible on this bug... :-( Modifying the indexing to allow priority queues could destabilize this part of Search and have unpredictable bugs arriving late in the game. It also does not prevent plug-in to launch low priority requests at the early beginning and slow down dramatically (may be 8 times slower!) products depending on it. This does not sound reasonable. Having a master switch may lead to users hitting the performance issue when starting a workspace which needs a full re-indexing, but having forgot that the preference was changed in this workspace a long time ago; then, of course, raising a bug against JDT/Core complaining that the indexing is slower with the new version! The last point is that it looks that nobody else than us (JDT) complains about this missing search matches... Either users use workaround the problem by importing source in the workspace (as I do) or never realize that there's a problem here... So, for all these reasons, the conclusion on this is that we stop work on this bug and we will remove it from the 3.5 plan, then wait for stronger needs before restart work in this area... Note that all the work already done here won't be done in vain as I found bug 251504 which may explain most of the unresolved problem with indexing (see bug 161409, bug 215271 and bug 108749)!
Is there any chance that this bug can be fixed in the 3.6 stream? You had mentioned that no one complains about this bug. But that is not true. *I* complain about it (albeit silently, whereas I should have raised a bug). :-)
*** Bug 226660 has been marked as a duplicate of this bug. ***
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
