No map-style constructor code assist with nested class

[mauromol]

Consider the following:

package test14
class Outer {
  static class Nested {
	  String foo
	  Integer bar
  }
}

And:

package test14
import test14.Outer.Nested
class Test14 {
  void foobar() {
	  def n = new Nested(|)
  }
}

Invoke code assist at "|": no suggestion is given to invoke a map-style constructor (like new Nested(foo: 'foo', bar: 5)). Neither is given if I start to type a property name (like new Nested(fo|)).

[eric-milles]

This should be ready to test with the caveat that the default constructor is missed at the moment. If you add an explicit no-arg constructor, all is well.

[mauromol]

I confirm with this use case works with 3.0.0.xx-201802112140-e47 but only if an explicit no-arg constructor is defined in Nested class.

[eric-milles]

This should be ready for test again soon without the restriction on default constructor. Please see note in #461 regarding difference between Groovy and Java (or binary class files). I was not able to get the constructor proposal for Java binaries due to an indexing difference. This is consistent with the Java editor.

[mauromol]

Hi Eric,
I confirm that with 3.0.0.xx-201802122322-e47 this scenario works well even if Nested does not declare any explicit no-arg constructor 👍
I don't understand though this sentence: "I was not able to get the constructor proposal for Java binaries due to an indexing difference.". First, if I understand it well, this means that the map-style constructor completion assist is not available if Nested were available only in an external JAR, because I just tested it and, if Outer and Nested are written in Java and available among the project source files, completion still works correctly just the case in which they are both written in Groovy. Have I understood it correctly?
What you mean by "This is consistent with the Java editor", considering that there's no map-style constructor invocation ability in Java?
As a last note, if I understand it correctly, this limitation in the binary indexing only applies to nested/inner classes (and not to top-level ones), doesn't it? Do you think it would be worth to open an enhancement request for JDT?

[eric-milles]

When I try to complete "new ComEnv" in the Java editor, I do not get a proposal for "CommandEnvironment(String cmdpath,String[] argv)", only for the type "CommandEnvironment - java.rmi.activation.ActivationGroupDesc". The same goes for the Groovy editor. That is, if the indexing supports location of a nested class through the constructor search method, ctors will be proposed. If that constructor is a no-arg or a default ctor can be assumed, then named parameter completions will be offered.

[mauromol]

When I try to complete "new ComEnv" in the Java editor, I do not get a proposal for "CommandEnvironment(String cmdpath,String[] argv)"

I'm still a bit confused. If you have the corresponding import statement (import java.rmi.activation.ActivationGroupDesc.CommandEnvironment), you do get that constructor proposal in the Java editor for CommandEnvironment(String cmdpath,String[] argv), I just tested it.
With the Groovy editor, I get it even if the import statement is missing (if I accept the proposal, the import statement is added automatically by Greclipse). Tested with Greclipse 3.0.0.xx-201802122322-e47.

[eric-milles]

Both Java and Groovy editors should propose type completions for a variable expression with no supporting import. Ex: "ComEnv" proposes "CommandEnvironment - java.rmi.activation.ActivationGroupDesc". The difference is the Groovy editor has support for finding inner type constructors without a supporting import. But that support has its limits. "new ComEnv" does not propose "CommandEnvironment(String cmdpath,String[] argv)- java.rmi.activation.ActivationGroupDesc" without the supporting import.

[mauromol]

Ok, I got it. I don't think this is a problem, though. So great work!