Incompatibility between Eclipse Code Recommenders and Groovy-Eclipse (restart helps)

[sewe]

Hi,

as a committer to Eclipse Code Recommenders, I’d like to bring Eclipse Bug 470406 to your attention. It causes content assist in the Groovy Editor to stop working – until a restart. Thereafter, everything is fine: the “Groovy Content” and “Java Proposals (Code Recommenders)” proposal kinds happily co-exist on the default content assist list (Java > Editor > Content Assist > Advanced preference page).

I am not entirely sure what’s going on yet. Our IntelligentCompletionProposalComputer enables and disables a few completion categories EnableContentAssistCategoryJob and DisableContentAssistCategoryJob, but Groovy-Eclipse’s computers are not among them. The fact that a restart fixes the problem suggests some kind of problem with propagating this preference change, though.

Does Groovy-Eclipse query the content assist preferences in any way?

(If possible, please continue the discussion over at the Eclipse Bugzilla.)

[sewe]

Dear Groovy-Eclipse team.

I dug a bit deeper as to why this happens. You can find my analysis in Eclipse Bug 470406. The problem seems to be related to GroovyConfiguration’s way to change private fields, but I am admittedly a bit lost w.r.t. Groovy-Eclipse inner workings. Any help in getting to the root of this incompatibility is thus greatly appreciated.

Conversely, if you need any help in figuring out what Eclipse Code Recommenders does or why, please ask.

[aclement]

Hi Andreas, I'm afraid at the moment there isn't anyone working on Groovy-Eclipse right now - so no-one to look at this.

[sewe]

Hi Andy. Sad to hear that Groovy-Eclipse is on hiatus.

Anyway, at Eclipse Code Recommenders we will probably work around this issue by using stricter heuristics to detect when we are in a Java source files. As I have learned, not every JavaEditor edits Java source code. It may just be a GroovyEditor working on a GroovyCompilationUnit, which just happens to extend a Java CompilationUnit…

[sewe]

Unfortunately, the workaround described in my previous comment is not possible: The problem occurs even if Code Recommenders just adds a no-op IJavaCompletionProposalComputer. Thus, this really must be fixed on the Groovy Eclipse side.

[eric-milles]

Is this still an issue with the latest snapshot builds of Groovy-Eclipse?

[sewe]

Hi @eric-milles. Since my initial investigation on this I haven’t tried to reproduce this again, as I am not really a Groovy user and the root cause seems to lie on the Groovy-Eclipse side. But the Eclipse Bug 470406 contains detailed steps to reproduce. So why don’t you try this out with the latest Goovy-Eclipse builds against the latest Eclipse Neon.2 (which includes the latest Code Recommenders 2.4.5) and report back here?

[eric-milles]

@sewe Sorry for the very long delay getting to this. I have been fixing some Content Assist issues over the past week and this issue caught my eye because our issue #290 references Code Recommenders as well.

I tried to follow the details as given in the Eclipse bug report and have somewhat of an idea. What I can say is that a new Groovy Editor tries to filter the list of Content Assist categories (private fCategories field from ContentAssistProcessor) to remove Java recommenders that are superseded by Groovy ones. This is done in the overridden method
org.eclipse.jface.text.source.SourceViewerConfiguration.getContentAssistant(ISourceViewer).

I tried a few things and each time that method gets called with a fresh ContentAssistProcessor. That is, fCategoryIteration is null. I don't think we want to change anything in the registry. That should be a global store that reflects the settings in the Preferences > Java > Editor > Content Assist > Advanced page. What I can do is filter the Code Recommenders categories from the Groovy Editor's content assist.

[sewe]

Sorry for the very long delay getting to this. I have been fixing some Content Assist issues over the past week and this issue caught my eye because our issue #290 references Code Recommenders as well.

@eric-milles Great to see that someone takes this up. I hope my previous analysis is helpful to you.

What I can do is filter the Code Recommenders categories from the Groovy Editor's content assist.

While a black list would work for the particular case of Code Recommenders, I don’t think this is the solution (unless there are virtually no other options); after all, anyone could add their own proposalCategory using the org.eclipse.jdt.ui.javaCompletionProposalComputer extension point. IMHO, a white list would be preferable (leaving only org.codehaus.groovy.eclipse.codeassist.category?).

That being said, I haven’t looked at Bug 470406 in a looong time. But maybe you can dumb down the steps to reproduce in that bug to something that doesn’t require Code Recommenders specifically, but just a small, no-op proposal computer in its own category. At least in 2015 that was enough to trigger the bug.