Community
Participate
Working Groups
I20051215 According to the stack traces posted in bug 121652, it looks like the UI is freezing while waiting for ClassFile#codeSelect(...) to return (codeSelect is done inside the main thread). Indenpendantly of the problem reported in bug 121652, codeSelect can take an arbitrary amount of time and should not run in the UI thread.
What makes you think that this call in the main thread got triggered by hovering? In some places, like pressing F3 or Ctrl+Click we have to do codeSelect(...) in the UI thread.
Sorry you're right. It is the hyperlink detector that causes the UI to freeze. Updated title accordingly.
There are no plans to change this. We don't call codeResolve() when moving with the mouse but only when the user wants to navigate i.e. already pressed the Ctrl key.
(In reply to comment #3) > We don't call codeResolve() when moving with > the mouse but only when the user wants to navigate i.e. already pressed the > Ctrl key. > For my education (and othes) why does this make it "ok" to freeze the UI thread?
>For my education (and othes) why does this make it "ok" to freeze the UI >thread? Sorry, but that isn't meant as a free ticket to freeze the UI ;-) For 90% of the code actions (e.g. refactoring, format, etc, navigation like F3) we use codeSelect(...) since we must get the Java element at the cursor position. Almost all JDT actions which are initiated by the user are using this pattern. Other stuff, like hovering or feeding a view which shows additional info is done in a separate background thread. I would expect to codeResolve to perform in a reasonable amount of time - taking one minute is simply not acceptable. Jerome, do you indeed suggest that JDT UI rewrites all its actions and first performs a codeSelect(...) in a background thread and then forks back to start the action?
I agree that taking one minute for codeSelect is not acceptable and I'm working on it in bug 121652. However you'll always find a user that wants to put its huge jar on a slow network drive and in this case, we can do all the optimization that we can, it is still going to take some time (several seconds) before codeSelect returns. So yes, I think that codeSelect should not be called in the UI thread.
I've removed the 'synchronize' around the codeSelect(...) which will not help if codeSelect(...) itself takes long but it will at least not wait while the CU is blocked by another thread. This will be committed right after M5.
Fixed in HEAD. Available in builds > N20060221-0010.
