Re: [jdt-dev] Introducing a slow jdt completion computer

[Mickael Istria <mistria@xxxxxxxxxx>]

On Mon, Jul 1, 2019 at 10:51 AM Gayan Perera <gayanper@xxxxxxxxx> wrote:

I was thinking if i can use this
https://github.com/eclipse/eclipse.platform.text/blob/master/org.eclipse.jface.text/src/org/eclipse/jface/text/contentassist/AsyncCompletionProposalPopup.java.

You shouldn't use it directly, but use `new ContentAssistant(true)` instead.

How to make use of this inside the JDT Editor.

JDT editors explicilty doesn't use async completion at the moment, and attempt to just switch it while keeping current completion proposal processors would fail with InvalidThreadAccess.

 

I think this is used for Generic Editors right ?

Yes.

 

since this is part of jface text i was assuming i might be able to use is for JDT Editor as well. What do you think?

You cannot change the JDT editor choice on that matter without subclassing the editor. You could subclass the JDT editor and try this but (additionally to the issue described above about InvalidThreadAccess) it would then be a different editor, that people would need to chose manually over JDT's one an so on.

There is no room for workarounds on this topic. It's JDT that needs to be improved; anything else will in the end result in more expensive, less reliable and less valuable work.

So if you want it remediated, I suggest you give a try to the related Platform and JDT patches already on Gerrit, and check whether they're working as expected and whether they help you -even a very small bit- in plugging you slow content assist processor.