Community
Participate
Working Groups
3.3 RC4 According to Jerome's comment in bug 188712, the open type dialog doesn't need to wait for the Java initializer job to finish. Results could show as soon as the search result is available. I think this probably has to do with testing if the history elements still exist.
In bug 188712 comment 4 Jerome says that the search engine returns results, although 'Initializing Java Tooling' is not finished or hasn't even started. My understanding is that 'Initializing Java Tooling' resolves all classpath containers. How can the search engine already provide correct results if not all classpath containers are resolved?
In the scenario described in bug 188712 comment 4, the container initialization is finished. So the SearchEngine has all the resolved information it needs.
> In the scenario described in bug 188712 comment 4, the container initialization > is finished. So the SearchEngine has all the resolved information it needs. We explicitly wait for the initializer job to finish in FilteredTypesSelectionDialog.ConsistencyRunnable.run(IProgressMonitor) line: 665 Afterwards, we do a dummy SearchEngine.searchAllTypeNames(..) and then check for each IType in the history whether its container's timestamp has changed on the file system. For changed types, we call IType.exists(). We have done the same in the old Open Type dialog, see TypeSelectionDialog2.ensureConsistency().ConsistencyRunnable.run(..) line: 293. Are you saying we don't need to wait for the JDT/Core initializer any more?
(In reply to comment #3) > Are you saying we don't need to wait for the JDT/Core initializer any more? I'm not sure why you ever had to wait for the 'Initializing Java Tooling' job to finish. In theory we were/are able to run the search engine by lazily initializing the containers concurrently with the 'Initializing Java Tooling' thread.
Dirk or Frederic, do you remember why we wait for the initializer job to finish? If not, I can remove the synchronization and test if the history is still consistent.
(In reply to comment #5) > Dirk or Frederic, do you remember why we wait for the initializer job to > finish? If not, I can remove the synchronization and test if the history is > still consistent. > I can't remember anything about this but I confirm that classpath entries will be resolved while initializing the JavaWorkspaceScope used for the request... One remark about the searchAllTypeNames request done in refreshSearchIndices: I saw that type name is set to "_______________" (after Kent's suggestion according to the code comment). If you look at numbers provided in bug 168354 comment 24, it could be interesting to set the package name too: the request would be then more than three times faster... :-)
Should we better ask for an new API instead of doing a dummy search that can take considerable time to perform?
(In reply to comment #7) > Should we better ask for an new API instead of doing a dummy search that can > take considerable time to perform? > Do you think about something like: prepare(SearchEngine)ForTypeNamesRequests?
nothing planed for 3.4
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.
