Community
Participate
Working Groups
Created attachment 87284 [details] Project to reproduce the bug Build ID: I20071213-1700 Eclipse 3.4 M4 and earlier Since some time it took extremely long on my system to open the type hierarchy, no matter on which class. Now I found out that the reason was a library referred to as a linked resource that did no longer exist. Using Filemon, it turned out that Eclipse obviously tried several times to access and index this jar file. There seems to be a waiting routine between the several tries, since the processor load and the disc activity is very low during the waiting period. During this time, the status bar always showed a message that one file is left to be indexed. Deleting the respective project solved the problem. The bug can be reproduced with the attached project (almost empty): - Open any workspace - Import the attached project using the "Import existing project" wizard - Open the Hierarchy view, e.g. on class Widget - Now the status line indicates that one file is left to be indexed until Eclipse gives up (?) trying to access the library See .project file for the linked resource.
Looks like a JDT Core bug to me. Please move back if not true.
The search scope contains a path to the missing .jar. When creating a type hierarchy, we run multiple search queries, each of them asking for indexes. As a side effect, we attempt to create the missing index for the missing jar. We should not add a missing .jar in the JavaSearchScope#enclosingProjectsAndJars
Created attachment 87888 [details] Proposed patch
Released for 3.4M5 in HEAD stream.
Using build I20080204-0010, I find disturbing results. Considering: - open brand new workspace; - import project from the zip file provided as first attachment; - open type Widget; - press F4 -- time 1; - hierarchy appears -- time 2; - open brand new workspace; - import plugins org.eclipse.jdt.core, org.eclipse.swt, org.eclipse.swt.win32.win32.x86; - open type Widget; - press F4 -- time 3; - hierarchy appears -- time 4. time 4 - time 3 is in the second range, while time 2 - time 1 is in the minute range.
I believe this needs further investigations.
Agreed.
The problem comes from the fact that the jar file is a linked resource which does not exist. Unfortunately, my fix and associated test cases does not handle this peculiar case. It also seems that I missed or forgot to test again the original use case to verify that it was really fixed, sorry for that. Move the target to M6 as I need some time to figure out what could be the fix in all possible cases (EFS for example)
Created attachment 90990 [details] New proposed patch New strategy to fix this issue: the job (SubTypeSearchJob) now gets the indexes list from its internal set when available instead of always building it from the index locations as done in the superclass (PatternSearchJob). This avoid to request the indexing of the missing jar several times, only valid indexes are used...
Released for 3.4M6 in HEAD stream. This time, I have verified that it works also with then project given in the bug description! So, hopefully, we should not fail the next milestone verification...
Verified for 3.4M6 using build I20080324-1300
