Missing code assist proposals to implement missing methods in anonymous inner class

[mauromol]

This is somewhat the old GRECLIPSE-1426.

Consider the following Java interface:

package test;

public interface I {
	void myMethod(String a, int b);
}

And the following Groovy class:

package test

class B { 
	void test() { 
		I myvar = new I(){ 
			 |
		} 
	} 
}

Invoke code assist at "|": I would expect to see the following proposal:

myMethod(String a, int b): void - Override method in 'I'

(indeed, it should be "implement missing method", rather than "override", but it's not that important)

However, no proposal at all is shown.

[eric-milles]

Probably a model thing again. If anonymous inners are represented in the JDT model the same way plain inners are, they should receive the same checks.

[eric-milles]

Ready to test

[mauromol]

I probably need to wait more for a new build, because on 3.1.0.xx-201808212342-e47 I still see no improvement here.

[mauromol]

Ok, a new build is available now: 3.1.0.xx-201808220545-e47.
There's an improvement, but this is what is produced after I choose to implement myMethod:

package test

class B {
  void test() {
    I myvar = new I() {
      void myMethod(String arg0, int arg1) {};|
    }
  }
}

(cursor at "|")
Expected behaviour:

package test

class B {
  void test() {
    I myvar = new I() {
      void myMethod(String a, int b) {
        |
      }
    }
  }
}

[eric-milles]

org.eclipse.jdt.internal.ui.text.java.OverrideCompletionProposal.updateReplacementString(IDocument, char, int, ImportRewrite) is returning the wrong node for ASTNode node= NodeFinder.perform(unit, offset, 1); and so the wrong parent type for node= ASTResolving.findParentType(node);. This prevents the abstract method lookup and so a plain stub is inserted.

[eric-milles]

I've got this working locally. I'm just working out some JDT resolve issues for anonymous inners that use a non-default constructor.

[eric-milles]

Ready to test

[mauromol]

The latest build that gets downloaded is 3.1.0.xx-201808242320-e47, and what I see with this is exactly the same behaviour I described in my previous comment.

[eric-milles]

[mauromol]

Hi Eric, I double checked again and I'm doing exactly this, but it does not work. What could be wrong?

I also tried to clean the project and rebuild the Java index, but it does not help.

[eric-milles]

I tried unix line endings, tabs, no space between ctor call and block start. All are generating the proper method stub for me. I'm not sure what is different.

[mauromol]

Is the build I'm using the right one?

[mauromol]

Just tried again on Oxygen.3a (Greclipse build 3.1.0.xx-201808271712-e47) on a fresh new workspace, no changes at all to the default Eclipse preferences, created a new Groovy project and copied and pasted the code in my original post, it does not work, I see the exact behaviour described above, void myMethod(String arg0, int arg1) {}; gets inserted.
No exception in the problems view, no error in the Groovy console:

Code select : 09:14:32 Code select starting on B.groovy at [ 72,0 ]
   Code select : 09:14:32 Event complete: 1ms: Code select: B.groovy
Content assist : 09:14:33 Starting content assist for B.groovy
Content assist : 09:14:33 Event complete: 2ms: Content assist for B.groovy
   Code select : 09:14:36 Code select starting on B.groovy at [ 72,0 ]
   Code select : 09:14:36 Event complete: 1ms: Code select: B.groovy
      Compiler : 09:14:36 Build Structure starting for B.groovy
AST Transforms : 09:14:36 Global transform groovy.grape.GrabAnnotationTransformation applied to B.groovy in 0ms
      Compiler : 09:14:36 Event complete: 12ms: Build structure: B.groovy : main
AST Transforms : 09:14:36 Global transform groovy.grape.GrabAnnotationTransformation applied to B.groovy in 0ms
   Code select : 09:14:36 Code select starting on B.groovy at [ 112,0 ]
   Code select : 09:14:36 Event complete: 31ms: Code select: B.groovy

Tried also on Photon (Greclipse build 3.1.0.xx-201808280019-e48) and still no joy, I get the exact same result.

[mauromol]

I was able to produce a test case that shows the problem I'm seeing, see #695.