Inconsistent Groovy completion in Default Proposals content assist if only Java Proposals (Code Recommenders) is enabled

[mauromol]

Found while working on #288. Ensure your Eclipse installation has JDT, Mylyn and Code Recommenders (I think Eclipse IDE for Java EE Developers have all three, but I'm not sure). Ensure that the Greclipse option "Guess the most likely parameters for method calls" is CHECKED.
Consider that code snippet:

package a
import static org.junit.Assert.*
import org.junit.After;
import org.junit.Test

final class A {
	MyBean m = new MyBean()

	class MyBean {
		String doSomething(String a, Integer b) {
		}
	}

	@Test final void test() {
		assertNu|
	}
}

Invoke content assist on | and accept assertNull(Object) from the first page of content assist (Default Proposals). The completion should be: assertNull(m). This is fine.

Now open Window | Preferences | Java | Editor | Content Assist | Advanced and UNCHECK both "Java Proposals" and "JavaProposals (Task-Focused)", but leave "Java Proposals (Code Recommenders)" checked.
Now test again the above scenario: the result of completion is: assertNull( (without the argument and with no leading closing bracket).
To get the right completion, you have to cycle through content assist pages and get to Groovy Proposals: if you accept assertNull(Object) from there, then the result completion is fine.

However, I don't think this is the right behaviour. I mean, if I'm using Java Proposals processed by Code Recommenders, I should not need the content assist pages for other Java Proposals (either Task-Focused or not). Also, assertNull(Object) is probably a Groovy proposal in any case, so I expect it to fall into the Default Proposals list in any case, and the result should be consistent in both cases (independently of the Java Proposals preferences). Another clue of this is that if the Greclipse option "Guess the most likely parameters for method calls" is UNCHECKED, the result is consistent independently of the above Java Proposals content assist configuration.

[eric-milles]

Java Proposals (Code Recommenders) is a 3rd party extension to Content Assist. If a completion from that set does not work in a Groovy editor, then that project should have a look. Groovy Proposals is intended to replace Java Proposals when using a Groovy editor. So it should be safe to check both Java Proposals and Groovy Proposals in the Default Proposal Kinds list. Because the Groovy Editor is an extension of the Java Editor, it may still be overriding some things that Java Proposals (Code Recommenders) was not tested with.

[mauromol]

This however does not explain why code assist breaks only in this specific case (with "Guess the most likely parameters for method calls" CHECKED). Please also note that Code Recommenders is an official Eclipse project (http://www.eclipse.org/recommenders/) and is being part of the Eclipse release train since Juno.
It's also included in the Eclipse IDE for Java EE Developers (http://www.eclipse.org/downloads/packages/eclipse-ide-java-ee-developers/neon3) and Eclipse IDE for Java Developers (http://www.eclipse.org/downloads/packages/eclipse-ide-java-developers/neon3).

So it's not so much "3rd party" :-)

[eric-milles]

Can you retest? The proposal categories from Code Recommenders (and others) should be disabled now within a Groovy Editor.

I'm not sure if the preference you mentioned was the real issue. I think opening the preferences with an open Groovy editor and changing the set of proposal categories was the problem. If you do still see odd completion behavior, can you confirm if closing and reopening the Groovy editor clears it up?

[mauromol]

The real issue is not the mentioned property by itself, but rather the combination of that property being true and the set of enabled proposal categories (if this includes only the Code Recommenders Java proposals without the standard and/or Mylyn Java Proposals category). Tomorrow I will retest and see what happens after your change, thank you!

[mauromol]

I just tried Greclipse 2.9.2.xx-201705112220-e46.
Now the content assist seems to be consistent, although you changed the wording and position of the options (I think they're better placed now). I would only say that probably "Use guessed arguments for method calls" should be enabled by default... unless you consider it experimental (instead, I had it disabled right now, I don't know whether it's because of previous option changing from me while testing this bug or rather because it's disabled by default).

So, I think the problem I reported is fixed now, thank you very much! 👍